#596 Reliability Issues Tracker a month ago

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.

#590 Long $KEYBOARD won't toggle closed 7 months ago

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

#588 wvkbd: falling back to uinput device when zwp-virtual-keyboard-manager-v1 is unavailable 8 months ago

Comment by ~aren on ~mil/sxmo-tickets

Is it possible to start wvkbd with any compositors that don't support the zwp-virtual-keyboard protocol? I'd expect the more limiting thing would be that wvkbd requires the wlr-layer-shell protocol.

I could see a case for making wvkbd more modular, it might be useful to be able to embed it in a lock screen (perhaps using a stripped down wayland-like protocol?).

Imo the best long term solution would be if the wayland folks could agree on a protocol for virtual keyboards (perhaps we should try to nudge them?), so we could support one way of doing things that works everywhere.

#20 Seatd should support systemd sd_notify 9 months ago

Comment by ~aren on ~kennylevinsen/seatd

Just happened to notice this issue, this looks like sdnotify-wrapper was designed for this sort of thing.

#582 deviceprofile should be manifested in INI files 9 months ago

Comment by ~aren on ~mil/sxmo-tickets

We don't hard code /usr/share we use XDG_DATA_DIRS, that was contributed like a year ago by wentam who was porting sxmo to nixos.

I'm also in favor of moving the scripts to /usr/share, it should be a simple patch if you'd like to try. You just need to move the files, and add the path in sxmo_init.sh.

#581 Auto generate deviceinfo 9 months ago

Comment by ~aren on ~mil/sxmo-tickets

I think getting rid of deviceprofiles is feasible if we rethink why have them (I already outline how this would work), but writing code that can accurately detect which input devices are used for what seems highly unlikely to me. Development teams with much more resources have given up on similar problems, gnome for example.

To quote from that pr

The original implementation of ::touch-mode tested for keyboard presence to know whether the OSK and other touch-only features were enabled.

However that didn't pan out, every webcam, card reader and kitchen sink like to live a second life as EV_KEY devices. This made the detection of actual external keyboards a much harder task than it sounds, and was thus removed in commit f8e2234c.

Your script also doesn't work on a pinephone, it doesn't detect anything for sxmo_monitor, or the power button, and gets the volume button wrong. If you want swaymsg outputs to test against feel free to ask on the sxmo irc, I can get you one from the PinePhone (non pro).

#581 Auto generate deviceinfo 9 months ago

Comment by ~aren on ~mil/sxmo-tickets

imo we should add the ability to have custom keybindings to bemenu, then we can bind volume up/down/power directly and get rid of our remapping hack. I started working on it at one point, but it's not exactly trivial because bemenu currently handles keybindings in the output specific code.

Another option (which is also quite hacky) would be to have a daemon that uses evdev to remap the volume keys to arrows when we tell it to. It would require elevated privileges (since it's not technically different form a keylogger), but might be easier to implement. interception-tools / caps2esc already does something like this, we could potentially borrow code from there if we want a device agnostic hack.

#582 deviceprofile should be manifested in INI files 9 months ago

Comment by ~aren on ~mil/sxmo-tickets

What would the benefit of this be, especially considering ini files are a pain to parse from a shell script?

#567 sxmo_init.sh not respecting user defined $XDG_RUNTIME_DIR 11 months ago

Comment by ~aren on ~mil/sxmo-tickets

I did a bit more research at some point and I think we should replace our xdg_runtime_dir handling with a pre-built solution that hooks into pam. Our solution doesn't get the permissions of the parent dir of xdg_runtime_dir right. It should be owned by root, but it's owned by the first user to log in, and any other user will get a permission denied error when sxmo_init tries to create xdg_runtime_dir. I don't think this would be easy to fix without some sort of privilege escalation in sxmo_init.sh which seems like a bad idea.

dumb_runtime_dir seems like a good option, but might need a little work to integrate into alpine without user configuration. pam-rundir and turnstile are other optinos, but are more complex / less well maintained. /etc/pam.d/base-session on alpine has a list of ones it looks for which was useful for finding these (and is probably where dumb_runtime_dir needs to be added).

#577 Sxmo appstore 1 year, 1 day ago

Comment by ~aren on ~mil/sxmo-tickets

I agree we should be careful not to end up with feature creep. What I'm interested in working towards is a menu system to help with managing the different components (point A above). I would prefer to add special cases for each of different motivating factors and combine them later if it they fit well together.

For splitting packages my current plan (although I haven't started working on it yet) is to add a check in sxmo_migrate.sh for packages that have been split from sxmo-utils, aren't installed, and the user hasn't been prompted about before. I think it can be done with just the package name, the sxmo version it was introduced in, and a description of the package. I expect this data, and probably some of the logic, could be repurposed to create a "sxmo modules" menu in the future.

Another option for splitting packages would be add the split packages to the dependencies of the common sxmo metapackage, fork a sxmo-minimal metapackage from it that doesn't have them, and use sxmo-minimal in new images. The issue with this is it would require a new metapackage for each release that splits new packages.

I discussed the SDM845/pipewire problem with briefly with anjan on irc, I think it would be fine to add a special case in the start hook since it's an unusual case, but anjan has a better handle on what that needs than I do.