We weren't clearing the read/write-in-progress flags if reading an spi
packet failed, which could leave those set indefinitely, making it
impossible to remove the module.
The multitouch core already sets these capabilities, together with a
bunch of others. Furthermore, since it also generates those events but
we don't, it's best to leave the setting of those capabilities to the
mt core in the first place.
Keyboards in particular are usually expected to wake a device from sleep
by default, but since this keyboard is attached to SPI (as opposed to,
say USB) this isn't the case here. So explicitly enable it for wake.
It will stay on while the system is suspended otherwise.
Note that we don't need to explicitly turn it back on again on resume,
as the higher layers will do that for us.
If system wakeup via keyboard/touchpad is enabled, then the GPE is
(re)enabled by the core just before going to sleep, and consequently
when a key is pressed to wake up the system the key-release generates
another GPE which our handler then receives (before the core can
re-disable the GPE). Since the SPI device is not ready, this results
in an ugly error message in dmesg.
So we now remember when we're suspended and just ignore all GPE's while
in that state.
Most operations are reads (i.e. keyboard and touchpad events);
furthermore the read-write-change delay is only necessary when actually
switching between read and write operations. So putting the delay after
each read is in most cases unnecessary. Hence this moves the delay to
the start of the writes instead (note that because each write is
followed by a read, it follows that each write is preceded by a read,
and so the delay at the start of the write is always necessary).
An info command is now sent to the touchpad during initialization, the
result of which contains a model id (or so we think). The model id is
then used instead of the dmi info to look up the touchpad dimensions
(that information does not appear to be present in the info command
results, unfortunately). This makes the lookup more robust for future
laptops that use the same touchpads.
Additionally, the input device's vendor and product id fields are now
filled in, using Synaptics' USB vendor id for the vendor id and the
above model id for the product id. The choice of vendor id is based on
the fact that that is what is used in the kernel rmi4 driver too (see
drivers/input/rmi4/rmi_driver.h).
This addresses #64.
Only the fn key can be swapped, because the key is handled specially in
the driver - for all other key remappings use the console and desktop
key mapping mechanisms.
This closes#59.
While desktop environments will also do this, this restores the
backlight level during early boot when, for example, the disk password
is being queried for.
Note that while Apple stores various settings in the EFI vars, they do
not store the keyboard backlight level there (and hence don't restore it
till the desktop comes up). I.e. there is no existing EFI var to use to
save this value, so this creates/uses a new one.
We aren't doing any runtime power management (and don't need to), and
even if we were it's unlikely our current suspend/resume callbacks
would be appropriate.
Furthermore, since our suspend/resume callbacks are not for runtime
power management, they don't need to (and should not) be inside
CONFIG_PM ifdef's.
Ronald Tschalär
Federico Lorenzi