~mil/sxmo-tickets#598: 
Lock - Unlock - Screenoff Loop Unreliable

I believe this is a common issue with a lot of people but when pressing the power button the behaviour of lock - unlock - screenoff is inconsistent.

For example:

  • Sometimes when pressing power button in suspend state wil bring you straight to unlock, sometimes will lock
  • Sometimes when locked will bring straight to screenoff again.

To me it seems like the main part of detecting presses of the button sometimes will loop twice for one button press.

This could be an issue with the button press threshold or the double press part of the script is an issue.

Status
REPORTED
Submitter
~hazardchem
Assigned to
No-one
Submitted
2 months ago
Updated
a month ago
Labels
No labels applied.

~magdesign 2 months ago*

I can confirm this behavior on pmos edge/sxmo 1.15.2/sway/op6

Before i was on stable with sxmo version 1.15.0 and I had none of this weird unlocking behaviors.

edit: when pressing powerbtn once, there is sometimes quite a delay. when waiting until pressing powerbtn a 2nd time, it does what it should. so if you grab the phone and just push power twice, then it does not unlock, so you push twice again, then all pushes go through and the phone is locked again. on my oneplus6 its only this delay (which is often but not alway..) which causes the issue.

~cortexmancer a month ago

We have pushed forward this issue on Matrix channel, and I am publishing the discoverys in this given commentary.

I am using sxmo with PinePhone running arch alarm, using sxmo-utils dantcnix package at version 1.15.2. At this enviroment I can confirm the lock -> screenoff behavior loop, and I can state I had experienced the lock -> unlock behavior, but without logs to state that.

For the lock -> screenoff loop, we had crossed the following logs, the first, at .local/state/sxmo.log:

15:46:18 sxmo_suspend.sh: going to suspend to crust
15:46:18 sxmo_suspend.sh: calling suspend with suspend_time <99999999>
15:47:13 sxmo_state.sh: transitioning to stage lock
15:47:13 sxmo_state.sh: this state is not suspendable
15:47:22 sxmo_state.sh: transitioning to stage unlock
15:47:22 sxmo_state.sh: this state is not suspendable
15:47:50 sxmo_state.sh: transitioning to stage screenoff
15:47:50 sxmo_state.sh: idle suspender started with timeout 3
15:47:54 sxmo_suspend.sh: going to suspend to crust
15:47:54 sxmo_suspend.sh: calling suspend with suspend_time <99999999>
15:49:11 sxmo_state.sh: transitioning to stage lock
15:49:11 sxmo_state.sh: this state is not suspendable
15:49:18 sxmo_state.sh: transitioning to stage screenoff
15:49:18 sxmo_state.sh: idle suspender started with timeout 3
15:49:23 sxmo_suspend.sh: going to suspend to crust
15:49:23 sxmo_suspend.sh: calling suspend with suspend_time <99999999>
15:49:24 sxmo_state.sh: transitioning to stage lock
15:49:24 sxmo_state.sh: this state is not suspendable
15:49:30 sxmo_state.sh: transitioning to stage unlock
15:49:30 sxmo_state.sh: this state is not suspendable

The second log, with doas libinput debug-events | stdbuf -oL awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' | grep 'event0' command:

2024-05-23 15:47:47 -event0   DEVICE_ADDED            axp20x-pek                        seat0 default group5  cap:k
2024-05-23 15:47:49 -event0   KEYBOARD_KEY            +4294967.291s     KEY_POWER (116) pressed
2024-05-23 15:47:49  event0   KEYBOARD_KEY            +0.162s   KEY_POWER (116) released
2024-05-23 15:49:10  event0   KEYBOARD_KEY            +5.872s   KEY_POWER (116) pressed
2024-05-23 15:49:10  event0   KEYBOARD_KEY            +5.873s   KEY_POWER (116) released
2024-05-23 15:49:17  event0   KEYBOARD_KEY            +11.676s  KEY_POWER (116) pressed
2024-05-23 15:49:17  event0   KEYBOARD_KEY            +11.904s  KEY_POWER (116) released
2024-05-23 15:49:23  event0   KEYBOARD_KEY            +17.936s  KEY_POWER (116) pressed
2024-05-23 15:49:24  event0   KEYBOARD_KEY            +18.124s  KEY_POWER (116) released
2024-05-23 15:49:29  event0   KEYBOARD_KEY            +23.693s  KEY_POWER (116) pressed
2024-05-23 15:49:29  event0   KEYBOARD_KEY            +23.861s  KEY_POWER (116) released

This log state that the lock -> screenoff behavior happens with only power_down_1, and as ArenM stated on chat, there is a difference of 8 seconds between each log statement. This seens to happen because of the variable SXMO_LOCK_IDLE_TIME that defaults to 8 and starts to count at the power button press, and not when the state changes. The suspection may be somekind of overhead at this flow, causing the incorrect behavior.

~stacyharper a month ago

I have applied some patch on sxmo_state.sh since 1.15.2. Even if I continue to experience inconsistencies, I'm now more confident on the sxmo scripts. Reading current state, and switching to another one should be race condition safe. But then if some events aren't actually received, sxmo will produce a very different output. This situation is even more worse on PinephonePro that just does not dispatch event if the power button is released too fast.

Register here or Log in to comment, or comment via email.