#598 Lock - Unlock - Screenoff Loop Unreliable 9 months ago

Comment by ~cortexmancer on ~mil/sxmo-tickets

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.