Lockscreen Freeze [Partial workaround found] Options

[klf!]

From time to time, but overall quite regularly, I'm not able to unlock debian on my gemini anymore.

Usually when on debian, with wifi on, the screen gets locked due to inactivity or manually by a short Fn+Esc hit. Unlocking normally works by hitting Esc (worldmap appears), typing pwd and Enter. So far so good. But from time to time, there is no response on the Esc-wakeup keystroke. The screen just stays black, no worldmap screen showing up.

Trying to login blindly (?screen wakeup problem?) did not succeed. I tried the whole process from login to shutdown blindly by keyboard(*), but the system/device does not respond in any way. Also waiting does not help (checked 30min+ more than once). The only solution in this case I found so far was Fn-Esc (aka "Off") until the device is powered off and reboot from scratch.
Reading the post over at xda-developers, I checked the device is still reachable via network (wifi): yes, and that I can connect via ssh: true (did not tried this before, because the WLAN I use is normally fully isolated from LAN and isolates the clients also, but I took the effort...;-). So the device and debian are basically still running fine. I can't see anything special from the logs (syslog, daemon.log, repowerd.log, debug, auth.log).

Anyone any idea how to go further?

(*) Esc, typing pwd, Enter, Ctrl+Esc, three times cursor up, one time right, four times down and two times Enter ;-)

Edit:
After having ssh available I found out that
   sudo service sddm restart
works around the issue by going to the initial login screen. But unfortunately that's not an option on the go...

[klampfenfreak]

nothing more about that very bad black screen bug?
tried to programm a key command with siver button, but seems that hardware keys, except the siver one won't get recognized anymore.

[Adam Boardman]

I also get this occasionally, and I've twice had the 'digital rain' which is a special variant where you have to disconnect the battery/fully flatten the device before you can get it to work again.

The current fudge around screen off/sleep needs re-thinking/fixing, currently its still set with the original first thing that sort of worked. I'm not happy with it but have yet to come up with a better plan.

Facts to work with:

1. Two key/keyboard drivers exist at a hardware/kernel level, one is the esc[on]+silver buttons, the other for the rest of the keyboard.
2. Only key presses on esc[on]+silver buttons can wake from a proper sleep.
3. Closing the device squashes the keys, and whilst working on this if you have the focus on a text input part of the UI then random keys can be seen after opening the device again.
4. When closed and you move the device about you can cause the keys to be pressed by shaking the device, this can include the 'esc' key which is an 'on' key when sleeping.

So the current solution involves/aims to achieve:

• Upstream kernel already turns off the main keyboard on sleep, and blocks main keyboard key presses after more than a few are simultaneously depressed
• Lid sensor detects close/open events
• On close we turn screen off and launch lock screen
• Lock screen eats esc[on]+silver buttons, silver button tells you the time, esc is ignored if the lid is closed

I couldn't get Planet to tell me how its handled on the Android side, though whether knowing that would have helped or not I don't know.

Possibly useful things for anyone else who wants to debug this, there are two ways of turning the screen off, both block the general keyboard, but let esc[on]+silver buttons work.

dpms screen off sometimes doesn't actually turn the backlight off, and will wake again from esc presses.

CODE

xset dpms force off

hwcomposer off turns the screen off in a way that it wont wake up from esc key presses, so its good to use when the lid is closed, and then get the lock screen to pickup the esc keypress and wake the device if open.

CODE

xrandr --output hwcomposer --off

These are the actual commands executed on your behalf by gemain branch of 'repowerd' with its interactions with 'gemain-lock'.

[Kiriririn]

I've got this 99% fixed on my Gemini, will dig up what I changed to get it working...

I've hacked a few things with repowerd suspend and with the lock screen key blocking, can't remember off hand which fixed this issue in particular, but it's defo along those lines

[Kiriririn]

I believe the change that fixed it for me was either:

Most likely:
https://github.com/lukefor/gemian-lock/comm...cfed97a4eee816f
(disregarding the system() calls which are to restore brightness and lock miravision state on resume)

Or something in here:
https://github.com/gemian/repowerd/compare/....lukefor:master
(most of this is to undo the cancer that is miravision, nicer backlight control, and 99% fixes the occasional hard freeze and battery drain in standby - so most if not all of it can be disregarded for this issue)

Anecdotally I'm at 22 days and counting of uptime with no weirdness (no freezes, no battery drain, standby working consistently), generally the only issue I've come across is disconnecting the charger without opening/closing lid stops it from entering standby, likewise with closing the lid too quickly sometimes

[Adam Boardman]

Possibly I've not looked in the right diff, but it looks like you've changed some bits to call some external scripts: /root/sleepy.sh etc, but not checked those in?

[Kiriririn]

Possibly I've not looked in the right diff, but it looks like you've changed some bits to call some external scripts: /root/sleepy.sh etc, but not checked those in?

Just hacks for my setup in there, cant remember if they even achieve anything

wakey

CODE

nmcli r all on

sleepy

CODE

killall -CONT /vendor/bin/aal
nnmcli r all off