Rewrite powerkey handler to allow more flexible configuration #221
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
Legacy option to allow bypassing of lockscreen with doubletap was broken. Make it work again. Also do not use raw numeric values to evaluate doubletap_gesture_policy. [mce] Make unblank and unlock via double tap work again
Having helper functions for both reading initial values and installing change notifiers allows builtin-gconf value tracking setup to be more compact and readable.
Taking double powerkey presses in use caused unconditional delay for single press handling. The actions that could be configured to be taken were not be differentiated based on display state, which made it impossible do one thing from display off and another one from display on. And since static configuration was used, changes did not take effect without restarting mce. Make possible actions as small and simple as possible. Allow combining them freely to choose actions taken. Use separate action combinations depending on whether display is on or off. Execute common parts of single and double press actions immediately when 1st powerkey press is released. Allow more flexibility for using custom dbus actions by allowing user configured method call to be made instead of signal broadcast. Use dynamic runtime changeable settings instead of static configuration from ini-files and add options to mcetool for changing all of them. Use the new functionality to: - apply device lock when double press is made from display on - unblank and hide lockscreen when double press is made from display off [mce] Rewrite powerkey handler to allow more flexible configuration. Fixes JB#23653
When display is automatically dimmed and then blanked there is a 30 second grace period before tklock gets applied. Since the device most likely also suspends soon after blanking the screen and we do not want to wake up just to toggle the tklock state, the end of grace period is evaluated when display is about to be turned on. This can cause ipc timing problems if powerkey/doubletap is configured also to remove the tklock. Also do opportunistic grace period end detection if the device wakes up from suspend due to reasons that would not cause the display to turn on. This should make it less likely that both lock and unlock happen at the same time. [mce] Re-evaluate autolock if device wakes up from suspend
If mce side state machines oscillate between tklock on and off, it can cause problems due to ui side trying to react to intermediate states. Use idle callback to delay sending of tklock state information so that only the final tklock state is communicated outside mce process. Hold a wakelock until the dbus ipc is actually made plus couple of seconds to make it more likely for ui side to have time to process the state change before device is allowed to suspend. Also clear last send state when tklock change requests are made over D-Bus. This way the state mce arrived at is always broadcast even if the request ends up getting ignored. [mce] Do not broadcast intermediate tklock changes over D-Bus
If device is suspended, device lock might get applied at unblank time. This in turn can leave the previously used application visible and usable. While the ideal solution would be to use iphb timer for locking the device while still suspended, using heuristics at least denies full access to application content if delayed device locking happens. [mce] Set tklock if devicelock gets applied immediately after unblanking
spiiroin
added a commit
that referenced
this pull request
Oct 29, 2014
Rewrite powerkey handler to allow more flexible configuration
|
can i comment on this? with current configuration we can't create more than two dbus mce signal. with previous configuration we can create as many signals as we need. |
|
Why would anyone ever need more than two of those ? :) |
|
we need six. single on, single off, double on, double off, long on, long off. |
|
Shortly put the idea at least was: There needs to be one dbus action to trigger visual power key menu. Add one extra to allow something special users come up with. Technically we could have 6 custom dbus actions, filed a bug for it: But do note that at least on Jolla phone long press from display off is probably not working as expected |
|
i understand you had some idea when you developed it, for other actions comma-separated list is great idea, but it ends as restricted thing for custom events. |
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.
No description provided.