OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Lockscreen Freeze [Partial workaround found]
klf!
post Sep 19 2018, 02:15 AM
Post #1





Group: Members
Posts: 2
Joined: 14-August 18
Member No.: 828,223



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...
Go to the top of the page
 
+Quote Post
klampfenfreak
post Nov 2 2018, 07:08 PM
Post #2





Group: Members
Posts: 6
Joined: 29-October 18
Member No.: 835,812



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.
Go to the top of the page
 
+Quote Post
Adam Boardman
post Nov 3 2018, 03:52 AM
Post #3





Group: Members
Posts: 130
Joined: 29-December 17
Member No.: 815,489



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'.
Go to the top of the page
 
+Quote Post
Kiriririn
post Nov 4 2018, 03:13 PM
Post #4





Group: Members
Posts: 62
Joined: 19-January 18
Member No.: 816,673



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
Go to the top of the page
 
+Quote Post
Kiriririn
post Nov 5 2018, 08:32 AM
Post #5





Group: Members
Posts: 62
Joined: 19-January 18
Member No.: 816,673



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
Go to the top of the page
 
+Quote Post
Adam Boardman
post Nov 5 2018, 11:17 AM
Post #6





Group: Members
Posts: 130
Joined: 29-December 17
Member No.: 815,489



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?
Go to the top of the page
 
+Quote Post
Kiriririn
post Nov 8 2018, 12:13 PM
Post #7





Group: Members
Posts: 62
Joined: 19-January 18
Member No.: 816,673



QUOTE(Adam Boardman @ Nov 5 2018, 08:17 PM) *
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

Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th February 2019 - 12:06 PM