~anjan

~

https://momi.ca

Trackers

~anjan/lift

Last active 1 year, 13 days ago

~anjan/fedi-go

Last active 2 years ago

~anjan/errbot-plugins

Last active 2 years ago

#252 Megapixels 1.0.1 doesn't work 10 hours ago

Comment by ~anjan on ~mil/sxmo-tickets

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.

#253 Battery status wrong when Bluetooth device is used 14 hours ago

Comment by ~anjan on ~mil/sxmo-tickets

See: #243

This bug should be fixed with the solution written in the comments. Closing since this is a duplicate.

REPORTED RESOLVED DUPLICATE

#252 Megapixels 1.0.1 doesn't work 14 hours ago

Comment by ~anjan on ~mil/sxmo-tickets

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

#240 Rethink how we lock SXMO 8 days ago

Comment by ~anjan on ~mil/sxmo-tickets

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.

#240 Rethink how we lock SXMO 8 days ago

Comment by ~anjan on ~mil/sxmo-tickets

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.

#240 Rethink how we lock SXMO 8 days ago

Comment by ~anjan on ~mil/sxmo-tickets

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.

#240 Rethink how we lock SXMO 8 days ago

Comment by ~anjan on ~mil/sxmo-tickets

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!

#55 Support Matrix 8 days ago

Comment by ~anjan on ~mil/sxmo-tickets

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.

#163 switch from xdm to tinydm 9 days ago

Comment by ~anjan on ~mil/sxmo-tickets

This bug depends on us fixing #44 as ~proycon notes.

#236 Enable compositor (new FR) 9 days ago

Comment by ~anjan on ~mil/sxmo-tickets

I think we should ideally put this information in the docs rather than having it hidden in the issue tracker. ~dinkocar , can you please send a patch to the mailing list with a patch?