~proycon added feature 3 years ago

~jpsamaroo 3 years 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 3 years 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 3 years 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 3 years ago

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

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

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

~anjan 3 years 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 years 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 years 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 3 years 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 3 years ago · edit

~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 3 years 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 3 years 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 3 years 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).

~anjan added ready 3 years ago

~anjan removed ready 3 years ago

~stacyharper REPORTED FIXED 2 years ago