~mil/sxmo-tickets#240: 
Rethink how we lock SXMO

Atm we got some issues

  • difficulties to track what happen. Are we leaving suspension by rtcwake, user input or crust ? We got no reliable way to determine it
  • add missing hooks (on screen off/on by example to stop and continue conky. Also on all kind of suspension wakeup plus dedicated ones to rtc, crust or user input)
  • impossible to track event from outside. We can't control some flows as killing the lock, then doing something, then starting it back in it previous state (suspended or screen-off). Maybe we could implement some kind of STOP signal handling
  • no security. We should add authentication
  • we should also be able to start dmenu while locked (or having a dedicated mode for this)

IMHO we should rather adapt existing sxmo_lock program to a daemon that we could control through ipc commands. Other daemons would be able to control it (example a proximitylock toggle). Hooks would be triggered on all kind of events.

We are also binding all of our user action to single scripts. We should be able to bind button inputs to ipc request to this daemon when locked. This will trim this part away from the daemon and simplify it. And give us more control depending on the contexts (ex pickup calls with buttons without having to unlock the screen)

Status
REPORTED
Submitter
~stacyharper
Assigned to
No-one
Submitted
2 months ago
Updated
22 days ago
Labels
feature

~jpsamaroo 2 months ago

+1 to this, especially IPC control. dbus would be the "right" way to do this, but since dbus isn't exactly the simplest thing to work with, we could implement a custom text-based IPC protocol over a domain/TCP socket.

~iv 2 months ago

A small remark on security. I've tried adding a slock part and a virtual keyboard to add authentication, see ticket #44. It works, but the issue that I could not get around is essentially the same one as in ticket #86. I fail to grab multitouch events, which would be a significant issue if something like Firefox is responding to them.

~anjan a month ago

This is definitely an important thing to fix. The thing Im worried about is the daemon crashing. Right now, the pinephone will sometimes not awake from screenlock and I must reboot in order to use my phone again. Not sure how we would solve this problem without programming a daemon though.

I think the course of action should be:

  1. Look into packaging ~iv's mobile slock implementation. I have tried to get it to compile yesterday and was having some issue. I will try again soon.
  2. Building a new locking mechanism with the benefit of hindsight we have from the current screenlock code.

I dont really like dbus and dbus is by in large not suckless. I would prefer if the implementation avoided that.

~craftyguy a month ago

I just packaged ~iv's mobile slock (for Alpine Linux) here: https://gitlab.alpinelinux.org/craftyguy/aports/-/commits/sxmo_screenlock

~anjan a month ago*

Ok, I have a working hack for the new locking mechanism in sxmo. It's on a branch called newlock in sxmo-utils:

tree: https://git.sr.ht/~mil/sxmo-utils/tree/newlock log: https://git.sr.ht/~mil/sxmo-utils/log/newlock

Patch as of today: https://paste.sr.ht/~anjan/a368a856a2d22f78cedbbaf9d69168846d3ed8a6

With my implementation, the user can run sxmo_screenlock.sh [lock|unlock|off|crust|rtc] at anytime from the command line to change the state of the phone at anytime. This allows for alot more scriptability. States ie. how we exited crust has been somewhat implemented (see: https://git.sr.ht/~mil/sxmo-utils/tree/newlock/item/scripts/core/sxmo_screenlock.sh#L108 ). When those modemmanager bugs are finished, I think we would be able to say that the modem woke the phone from suspend or button press. As we know, crust is currently broken for the modem so I cannot say for certain.

I have also decoupled the input listener from the main loop: https://git.sr.ht/~mil/sxmo-utils/commit/8f2cfb98bb4a9a96b4b15a5d830be5262c1b30ae

The phone is unlocked after one button press...I think this should be fine as long as we also implement slock.

Overall, this implementation will not require a daemon to be running and is much simplier. The user can always ssh in and unlock their phone if the inputhandler crashes. This is very important since Ive lost alot of work as a result of sxmo_screenlock.c crashing. We use sxmo_screenlock.sh now which is a oneshot shell script.

Let me know what you guys think!

~anjan a month ago

I found a bug with my implementation. Suppose I run sxmo_screenlock.sh rtc 10 and press the button 2 seconds in, the .local/run/sxmo.suspend.reason file says rtc when the button press is the reason it came out of crust.

I dont know to fix this other than looking through /sys/* and reading the docs for wakealarm.

~anjan a month ago

the issue mentioned in my last comment should be fixed with this commit: https://git.sr.ht/~mil/sxmo-utils/commit/2a7c042

Basically, each wakeup source has a active_count file that increments everytime we wake using that source. The button's wakeup source is stuck at 0 which is...kind of annoying. Hopefully this is just a kernel bug. Regardless, I think I programmed around that issue above.

Im still unsure how to handle waking up from sxmo_screenlock.sh crust but afaik, that doesnt have any bugs.

The file is littered with todos but it's a good start.

~anjan a month ago

You cannot use inotify on a /dev file. As such https://git.sr.ht/~mil/sxmo-utils/commit/8f2cfb98bb4a9a96b4b15a5d830be5262c1b30ae is wrong. For now, the command line via ssh is the only way to lock and unlock the phone. crust works fine.

~proycon 27 days ago

I'm testing the new lock screen from the newlock branch a bit. After locking and unlocking, the touchscreen is no longer responsive. I suspect https://git.sr.ht/~mil/sxmo-utils/commit/7ee30c36adcb7edd99907a96647ebe7cd9aff07e might be the culprit?

~proycon 27 days ago

also, lisgd doesn't restart after unlock.. I wonder if there's something wrong on my installation because I imagine you probably took care of such basics already.

~proycon 27 days ago

ok, never mind me, my dwm was out of date. now it works

~anjan 25 days ago

I have been using newlock for a couple days now. It's pretty great! I found that the screen turns on and stays on when mpv is playing. Can anyone else reproduce?

~arjunaithal 25 days ago

One issue i have observed -

  1. open dmenu.
  2. Incoming call rings.
  3. The call pick menu is not visible even after closing the dmenu.

~stacyharper 22 days ago

One issue i have observed -

  1. open dmenu.
  2. Incoming call rings.
  3. The call pick menu is not visible even after closing the dmenu.

Yeah we should find a way to handle this. This is a global issue as some menu could prevent other to display themselves.

Idealy, new menus should enqueue the displayed one and take it place.

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