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
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.
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.
I'd rather have one ticket per issue, that way we can use the tools that sr.ht provides to track the status.
Yeah happy to do that if thats how things work for sr.ht.