Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc updates #70

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

Misc updates #70

wants to merge 19 commits into from

Conversation

roadrunner2
Copy link
Contributor

This is a collection of clean-ups, small fixes, and a couple new features. Apologies for not creating separate pull requests, but the individual commits should be clear.

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.
These are gcc specific, but gcc by default already generates the
alignment and packing we want.
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.
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.
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.
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).
Otherwise we might try to handle an interrupt on a non-enabled SPI
device.
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.
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.
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.
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.
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.
efivar_entry_set_safe() returns standard status codes, not efi ones.
Thanks to Lukas Wunner for catching that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant