~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
5 months ago
Updated
2 months ago
Labels
feature

~jpsamaroo 5 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 5 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 4 months 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 4 months ago

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

~anjan 4 months 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 4 months 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 4 months 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 4 months 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 3 months 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 3 months 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 3 months ago

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

~anjan 3 months 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 3 months 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 3 months 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.

~baroque0 2 months ago

(Before i describe what is a minor annoyance to me, i want to congratulate eveyrone for the amazing work done on this issue, and the rest!! sxmo really rox)

I figured this annoying pattern:

  • device in crust (red LED)
  • incoming notification (SMS, call, dino message, etc.) sometimes notification has a counter (min, sec) that keeps on counting...
  • device goes to suspend (pink+green LED )
  • battery gets drained very fast...

I don't know anything about the internals of sxmo to be able to formulate anything but an uneducated guess.. But my intuition is that the same scripts responsible for taking the system out of crust and running the changes of state (alerts, LEDs, notifications, etc.) should somehow attempt to put the system back to crust.

Does that make sense?

~trbl 2 months ago

~baroque0, could this be the same issue I faced recently in #285 ? The fix was to run sxmo_migrate.sh and letting it create the rtcwake hook.

~stacyharper 2 months ago

The modemmonitor.sh script is responsible to put the phone back to crust after receiving a sms or missed a call.

I can relate there is an issue. My phone was found not in crust after receiving a sms.

~stacyharper 2 months ago

Firstly I found a hole with the crust function. The rtc one was storing the wake up reason correctly but not the crust one.

I think there is another issue cause I relate the problem and I am using rtc in my device. Probably related to the last state when modemmonitor check it but this would require more debug. I'll test harder later this day

~stacyharper 2 months ago

By the way, the postwake and rtcwake hooks are not triggered when the wake reason is "modem". So there should be not blinking led for 5/10 s then automatic returning to crust. The modemmonitor handle (incoming call then missed call + 5 s to crust) OR (sms notification + 5 s to crust).

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