-
Notifications
You must be signed in to change notification settings - Fork 112
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
roadrunner2
wants to merge
19
commits into
cb22:master
Choose a base branch
from
roadrunner2:misc-updates
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Misc updates #70
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This is a little more precise.
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.