~phartman


#562 pinephone's +2233445566 number and pnc 3 days ago

Ticket created by ~phartman on ~mil/sxmo-tickets

pinephone's biktorgj's firmware has a special number +2233445566 that you can text for version and other neat information. However, that number does not play nice with pnc find. (One area this manifests is in the contextmenu for Reply and Conversation --- it won't let you.)

So not sure what to do about it just yet.

#559 ghost wakeups overnight 5 days ago

Comment by ~phartman on ~mil/sxmo-tickets

Setup a script last night to monitor /sys/class/wakeup/wakeup* and discovered the culprit: wakeup4 which is the battery. Again, while plugged in and suspended, it woke up about 6 or 7 times thanks to battery. Here's a patch:

https://lists.sr.ht/~mil/sxmo-devel/patches/38447

REPORTED RESOLVED CLOSED

#384 Still unreliable rtc wake with cronjobs 6 days ago

Comment by ~phartman on ~mil/sxmo-tickets

Small update, since I went down a debugging rabbithole:

o Problem has nothing to do with sxmo_mutex.sh locks.

o Not a race condition between cronjobs (only one cronjob).

o One proposal (which does fix it for me):

  • in sxmo_hook_mnc.sh bump the time from 10 to 70 to give crond enough time to poll after waking from suspend.
  • in sxmo_hook_postwake.sh add an [ "$UNSUSPENDREASON" = "rtc" ] && sudo /etc/initi.d/crond restart (maybe not necessary but at least gives crond that nudge when waking from reason)

I had both of these for about a year now and everything was working great. I recently reverted back to the default mnc and I saw the bug again.

o Long term solution? Write our own scheduler!

#559 ghost wakeups overnight 6 days ago

Comment by ~phartman on ~mil/sxmo-tickets

Update: tested again last night with phone unplugged overnight, and did not receive any of the ghost wakeups at all. So I only get the ghost wakeups when I'm plugged in overnight.

This suggests that the power plug / usb-c are triggering the wakes (even though they are not registered in POWERRTC="/sys/class/wakeup/wakeup${SXMO_POWERRTC:-5}/active_count" (see sxmo_suspend.sh).

#561 bounty: sxmo_contacts.sh:prepare_contacts_list() is slow 8 days ago

Comment by ~phartman on ~mil/sxmo-tickets

REPORTED RESOLVED CLOSED

#561 bounty: sxmo_contacts.sh:prepare_contacts_list() is slow 8 days ago

Comment by ~phartman on ~mil/sxmo-tickets

Ok, I did a little digging and think I found the big bottleneck here: https://lists.sr.ht/~mil/sxmo-devel/patches/38362

#341 data rarely works after CRUST 8 days ago

low-priority added by ~phartman on ~mil/sxmo-tickets

#341 data rarely works after CRUST 8 days ago

high-priority removed by ~phartman on ~mil/sxmo-tickets

#561 bounty: sxmo_contacts.sh:prepare_contacts_list() is slow 8 days ago

Ticket created by ~phartman on ~mil/sxmo-tickets

I have a pretty big ~/.local/share/sxmo/modem/modemlog.tsv now, and I noticed that "Texts" from main menu took upwards of two or three seconds to load! So I dug about to see who is causing the slowness, and I think its that awful awk stuff in prepare_contacts_list().

Type sxmo_contacts.sh --texted to see.

So, code does: grep "(recv|sent)_(txt|mms|vvm)" ~/.local/share/sxmo/modem/modemlog.tsv

and pipes that into the aforementioned function which then parses the crap out of it.

I think we can greatly simplify what is going on here.

I'm calling this a "bounty" in case anyone wants to take up the task. Writing up the issue to put it on the radar.

#520 Pinephone pulse audio configuration is not listing in audio menu 9 days ago

Comment by ~phartman on ~mil/sxmo-tickets

REPORTED RESOLVED IMPLEMENTED