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:
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.
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.
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.
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.