I said it was not our bug since ~cnx said:
It was diagnosed to be an issue with GTK+ 4
Reading the original thread, I see the user could not run gtk4-demo. I was able to run gtk4-demo on my pinephone with sxmo+pmOS stable. The only code in sxmo that could cause this error is here: https://git.sr.ht/~mil/sxmo-utils/tree/master/item/configs If you find something, let me know.
By the way, the error says "To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior". I can suggest changing the environmental variable so we can debug this issue better.
This bug should be fixed with the solution written in the comments. Closing since this is a duplicate.
REPORTED RESOLVED DUPLICATE
Since sxmo now has stable builds, it is recommended that users that depend on daily driving their pinephone use pmOS stable + sxmo.
REPORTED RESOLVED NOT_OUR_BUG
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.
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 crustbut afaik, that doesnt have any bugs.
The file is littered with todos but it's a good start.
I found a bug with my implementation. Suppose I run
sxmo_screenlock.sh rtc 10and press the button 2 seconds in, the
rtcwhen 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.
Ok, I have a working hack for the new locking mechanism in sxmo. It's on a branch called
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!
We have just merged a patch with support for gomuks, a matrix client: https://lists.sr.ht/~mil/sxmo-devel/patches/22440
I would try out this client and add to sxmo_appmenu.sh any commands that would make that client more user friendly on a phone.
This bug depends on us fixing #44 as ~proycon notes.