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.

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

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.

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).

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.

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

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).

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.

Looks like pmos edge just pushed a new callaudiod that fixes it for me.

On Mon, May 22, 2023 at 04:04:33PM +0000, ~aren wrote:

This might be related https://gitlab.com/postmarketOS/pmaports/-/issues/2115.

Can someone who's having trouble with callaudiod provide the output of pactl list cards? I think it's possible it's not loading the right alsa ucm file and there's no voice call profile which would cause the described output from callaudiod.

Also there's a couple secondary bugs in your report that we should probably address:

The current release is 1.14, I'm guessing you got the version from the config menu entry which is out of date.

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

We definitely need to cleanup the call files if this happens.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-239221

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

Just updated today and got the problem...

On Mon, May 22, 2023 at 04:04:33PM +0000, ~aren wrote:

This might be related https://gitlab.com/postmarketOS/pmaports/-/issues/2115.

Can someone who's having trouble with callaudiod provide the output of pactl list cards? I think it's possible it's not loading the right alsa ucm file and there's no voice call profile which would cause the described output from callaudiod.

Also there's a couple secondary bugs in your report that we should probably address:

The current release is 1.14, I'm guessing you got the version from the config menu entry which is out of date.

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

We definitely need to cleanup the call files if this happens.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-239221

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