feature added by ~aren on ~mil/sxmo-tickets
Ticket created by ~aren on ~mil/sxmo-tickets
This is a place to track notes on implementation, these features have a good chance of being included in sxmo in the near future.
#Goals
- Allow users to swap out the program managing users services (currently only superd is supported)
- Must be possible to switch by (un)installing packages only
- No dependencies on a specific service manager
#Motivation
On distros with systemd already installed, we're just adding bloat to the system by adding another service manager (superd). In the interest of keeping the system minimal, we should be able to manage user services via systemd in this case.
With pmos adding support for users choosing which init system to use, it probably makes sense for us to do the same
#Discussion
I think this can be implemented by replacing all our calls to superd with a hook. When swapping via the package manager, it can replace the default for that hook so everything works seamlessly. Users who want to change init system can replace the hook, and all the services that sxmo ships.
The only downside to this I can think of is that we can't install services for multiple service managers simultaneously, but I'm not sure where this would be an issue except perhaps multi-uesr systems.
on ~mil/sxmo-tickets
On Sat Oct 26, 2024 at 7:48 PM CEST, ~aren wrote:
Yes, that sounds quite feasible and a good idea. (I don't think the rc suffix is common in Alpine but we can just do a less advertised v1.17 and a final v1.18)
We basically do this already, there always seem to be a few bugs that turn up after making a release, which tend to get fixed in 1.X.1 or 1.X.2. So perhaps the thing to do is to make a 1.17 release sooner rather than later, and plan on a couple of point releases to clean up the loose ends?
Agreed, would be good to really something soonish once all the important parts we want in are in place (e.g. peanutbutter).
Comment by ~aren on ~mil/sxmo-tickets
Yes, that sounds quite feasible and a good idea. (I don't think the rc suffix is common in Alpine but we can just do a less advertised v1.17 and a final v1.18)
We basically do this already, there always seem to be a few bugs that turn up after making a release, which tend to get fixed in 1.X.1 or 1.X.2. So perhaps the thing to do is to make a 1.17 release sooner rather than later, and plan on a couple of point releases to clean up the loose ends?
on ~mil/sxmo-tickets
On Sat Oct 26, 2024 at 4:30 PM CEST, ~aren wrote:
I'd prefer to have the polkit rule in sxmo-utils, that's much easier to keep track of than making sure every distro gets the right one.
Right, agreed, I just submitted a patch for that.
I don't know what alpine packaging is like, but if we were to make a pre-release (e.g. v1.17-rc1) could that be packaged in alpine edge to get some wider testing?
Yes, that sounds quite feasible and a good idea. (I don't think the rc suffix is common in Alpine but we can just do a less advertised v1.17 and a final v1.18)
--
Maarten van Gompel (proycon)
web: https://proycon.anaproy.nl gpg: 0x39FE11201A31555C
Comment by ~aren on ~mil/sxmo-tickets
I'd prefer to have the polkit rule in sxmo-utils, that's much easier to keep track of than making sure every distro gets the right one.
I don't know what alpine packaging is like, but if we were to make a pre-release (e.g. v1.17-rc1) could that be packaged in alpine edge to get some wider testing?
Comment by ~aren on ~mil/sxmo-tickets
You'll be better off creating sxmo packages for void, sxmo-build just installs dependencies and calls
make installwhich is really the package managers job. Also it never got the dependencies right for anything but alpine, the other distros were more like proof-of-concepts.If you need help packaging things I'd be happy to help out when I have time, feel free to ping me in the irc channel.
Comment by ~aren on ~mil/sxmo-tickets
It looks like that change profile_template is already included. SXMO_OS should be set to the value of ID in /etc/os-release, so it might just work? I'm not sure where your backgrounds package puts things, and what pmos / alpine put in os-release
Comment by ~aren on ~mil/sxmo-tickets
On Sun, Apr 14, 2024 at 10:39:24AM +0000, ~hazardchem wrote:
After reading a blog post by Drew DeVault (on mobile linux) and polling the sxmo irc I have come across some reliability issues that we should look at addressing
- Lock, Unlock, and Screenoff loop behaves inconsistently:
- Single button press will sometimes bring to an unexpected state.
- Waking up when there is a call coming in, and the delay to displaying a call
- And also trying to unlock the screen see point above
- Battery percentage update post suspend, sometimes will take 5-10 seconds to update
Yup bugs, I'll take a look at them if I can find the time.
- DWM vs Sway giving inconsistent experiences
- Possibly the easiest way to solve this is to change dwm to i3 as they its the x11 version of sway but there could be opposition to that (myself would be opposed to that change)
The only thing to do here is file bugs / send patches and we'll try to get it fixed.
I don't think switching to i3 much as most of the difference are between xorg and wayland, and less between window manager specifics.
- Volume bar is laggier than the brightness bar to display
This is because each 5% increment requires a call from lisgd to the inputhandler to pactl / brightnessctl. IIRC the case statement in the inputhandler takes a while to execute, on top of forking several shells which will take 5ms-10ms each and pactl takes 50ms-100ms. All together I think one loop is on the range of 200ms-300ms.
There's a few things I can think of that might help:
- try moving the pactl calls straight into the lisgd commandline
- modify lisgd to print gestures to stdout instead of calling system, and keep the input handler hook always running (this saves a fork)
- batch events, e.g. if 3 volume up gestures are triggered while one is processing, instead of calling the script three times, call it with a count of 3
- (more aggressive) have some daemon that handles gestures which can keep an open connection to pulse/pipewire. pactl alone takes 50ms-100ms on my phone, and I wouldn't be surprised if a good portion of that is setting up the dbus connection.
The main goal of this bug report is to provide some focus on how to get some reliability issues sorted and visibility of them. This can be updated to follow more issues that arise as well.
Let me know your thoughts on the topic as this is the only way we are going to get progress is by talking about them.
I'd rather have one ticket per issue, that way we can use the tools that sr.ht provides to track the status.
Comment by ~aren on ~mil/sxmo-tickets
We uesd pkill -f for a while, I don't remember there being a reason to remove it. Based on git blame it was just a careless refactoring so I resent the patch https://lists.sr.ht/~mil/sxmo-devel/%3C20231003182204.1861761-1-aren%40peacevolution.org%3E