#427 sxmo_networkmonitor.sh: what's the purpose? a day ago

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

I'm not sure there is one. And it doesn't seem to detect network down state changes. When I do nmcli c down MyWifiName, dbus will signal:

uint32 50
uint32 60

When I do nmcli c up MyWifiName, dbus will signal:

uint32 40
uint32 60
uint32 70

But sxmo_networkmonitor.sh only detects the 70. So it fails to detect network down, but it does detect a network up. But in any case, can't we accomplish this with a script in /etc/NetworkManager/dispatcher.d/? It seems all this bit of code is doing is running sxmo_statusbarupdate.sh, so we could add:

#!/usr/bin/env sh
[ "$event" = "up" ] && sxmo_statusbarupdate.sh
[ "$event" = "down" ] && sxmo_statusbarupdate.sh

Here's the SPEC sheet for StateChanged: https://people.freedesktop.org/~lkundrak/nm-docs/nm-dbus-types.html#NMDeviceState

Happy to hear why we are doing it this way rather than the other way!!!

Also, I got interested in this because pkill -f sxmo_networkmonitor.sh kills my dwm session! Still not sure why that happens :P If we keep sxmo_networkmonitor dbus, I propose we move it into sxmo_modemmonitor.sh alongside the other dbus monitors...

#426 some icons in nerd fonts display wrong 3 days ago

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

This is FYI, maybe we put a comment in sxmo_common.sh. https://github.com/ryanoasis/nerd-fonts/issues/478#issuecomment-653251699

#353 screeeeeeeeeaaaaaming inputtttt 7 days ago

Comment by ~phartman on ~mil/sxmo-tickets

Switched over to dwm for last couple weeks, and I have never experienced it, whereas I experienced it once a day or so in sway. So I guess it is something sway-related, likely?

#425 status bar: red [error reading from status command] because of amixer 9 days ago

Comment by ~phartman on ~mil/sxmo-tickets


This should fix the first issue.

#415 launch sxmo_modemmonitor.sh from ssh causes unexpected behavior 20 days ago

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

This is more a not to myself and anyone else, so I can remember to chase this down at some point. It is what the title says. One unexpected behavior is that the sxmo_screenlock.sh getCurState call in sxmo_notificationwrite.sh will return the wrong value and give purple LEDs or something. This is because it can't 'find' the wm and assumes 'ssh', and something more complicated I need to chase down.

Very low priority, because other than debuggers, who actually launches sxmo_modemmonitor.sh from ssh?

#404 multi-line sms's lag behind 25 days ago

Comment by ~phartman on ~mil/sxmo-tickets

I can't replicate this anymore. Close me!

#400 auto-configure network data 25 days ago

Comment by ~phartman on ~mil/sxmo-tickets

I updated the documentation for mms to include this information, so we can close this ticket.

#353 screeeeeeeeeaaaaaming inputtttt 25 days ago

Comment by ~phartman on ~mil/sxmo-tickets

I've had this happen now on occasion, and I'm starting to think this is hardware. If I twist the phone chassis, it'll often fix it. (Could just be in my head.) Any confirmation that this happens on another OS?

#409 wifi + modem mucks with resolv.conf 30 days ago

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

If you have both wifi and modem on, NetworkManager will generate a broken resolv.conf, since I think it can only have 3 entries due to musl limitations. (I think that's the reason at least.) Usually this isn't noticed since either modem or wifi's nameservers will work for day-to-day usage. But with mmsdtng, we MUST use the modem's nameserver to unpack the payload of MMS messages.

I ended up setting dns=none in /etc/NetworkManager/NetworkManager.conf and establishing a static /etc/resolv.conf.

But we need a more automatic solution for users, and unfortunately I haven't been smart enough to figure out what that solution would be.

So I thought I'd open this ticket in case someone can figure that out for us!

#407 items that should be treated by is_idle a month ago

Comment by ~phartman on ~mil/sxmo-tickets