Please use git send-email to send this to the sxmo-devel mailing list at ~mil/sxmo-devel@lists.sr.ht . If you haven't sent emails using git before https://git-send-email.io/ is a good guide.

From quickly skimming your patch it's an interesting idea, but your implementation has some issues:

• you should use $XDG_CONFIG_HONE/sxmo instead of $HOME or /home/user
• we already load configuration from ~/.profile and $XDG_CONFIG_HOME/sxmo/profile, which serves the same purpose as the sxmocfg file you added.
• you might want to consider using the name of the ring mode instead of a number (eg mute instead of 0)

Limiting the number of calls to superd would be great for portability, on arch I have to be very careful to remove pipewire, mmsd, and vvmd from my start hook, because otherwise superd will fail to start them (because systemd already has), and enter an infinite restart loop which uses up a bunch of cpu power.

If superd could handle service dependencies it would be possible to create a "meta-service" for sway / dwm specific services. I don't think we can remove calls completely, but that would probably make it possible to have just a few.

Mmsd and vvmd have a dbus interface for configuration, that (iiuc) is preferred for configuration because it doesn't require restarting it. It's possible we could switch to that (perhaps by adding support to mmsctl?), although it would sort of be trading one mess for another.

Ideally, I'd like to remove all superctl start statements from our code, but that wouldn't work well with sway/dwm live-switching.

Some services we need to run with superd. Is a good division of these the ones prefixed with "sxmo", and the ones not?

It looks like maybe just mmsd/vvmd are services we have toggles for that don't start with "sxmo" (i.e. systemd users would want systemd to manage). ~aren is that right?

This is an interesting challenge, I think having a VISUAL_EDITOR environment variable (rather than using sxmo_terminal.sh $EDITOR) would be the simplest way to support gui editors. It's possible that using xdg-open could also achieve the same thing, I'm not sure which would be better.

I get this now and then, especially with the keyboard case.

I was thinking about some limit.

On Thu, Jun 30, 2022 at 12:54:13AM +0000, ~aren wrote:

Sometimes when unlocking the phone (possibly only when waking from suspend) the power key can get stuck, causing terminal windows to open indefinitely. The phone doesn't power it's self off, so I think the key up event for the power button probably gets lost before sway gets a chance to handle it.

If this is caught early enough pressing the power button will reset sxmo to a more "normal" state (stop it from continuously opening terminals), this only works if it is caught in time though. I have unlocked my (overheating) phone to find hundreds of terminal windows on several occasions.

A better workaround might be to disable the key repeat functionality in the multikey script, which is how the dwm version currently behaves.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/517

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Sometimes when unlocking the phone (possibly only when waking from suspend) the power key can get stuck, causing terminal windows to open indefinitely. The phone doesn't power it's self off, so I think the key up event for the power button probably gets lost before sway gets a chance to handle it.

If this is caught early enough pressing the power button will reset sxmo to a more "normal" state (stop it from continuously opening terminals), this only works if it is caught in time though. I have unlocked my (overheating) phone to find hundreds of terminal windows on several occasions.

A better workaround might be to disable the key repeat functionality in the multikey script, which is how the dwm version currently behaves.

I believe this is an issue with sway not emulating a mouse correctly, specifically not reporting a device for the emulated events if there isn't a physical mouse. Sway is supposed to emulate mouse events when the application doesn't support touch.

I talked to someone else about this on the Danctnix (arch) channel a couple days ago, who filed an issue with sway https://github.com/swaywm/sway/issues/7052

I suspect this has the same root cause as #486, also unclutter shouldn't be related since unclutter is xorg specific.

sxmo_version.sh reports Sxmo v20220328-2709-gf553930a96 on pmos

When making a call fails (if there's no service for example) , it's entered into the modemlog as a missed call, and a missed call notification is displayed

I think this should reopened, since everything launched at startup still needs to be in the start hook. Sxmo doesn't currently use superd to autostart it's daemons.