I did a fresh install of pmOS edge with the official build of sxmo-de-sway 1.9.0 on my OG pinephone.

When I pressed the "Camera" item on the system menu, nothing happened.

I then tried to run megapixels from the command line and got some sort of GL_FRAMEBUFFER assertion failure, and megapixels crashed before opening the window.

I then tried again, from the command line, and it worked. However, there is still an error about "Failed to get display configuration: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.gnome.Mutter.DisplayConfig" does not exist.

I tried opening megapixels again from the command line, and got the GL_FRAMEBUFFER assertion failure again.

Any ideas?

I got this error with a fresh install of the official build of pmOS Edge with sxmo-de-sway 1.9.0 on my OG pinephone. It happened for me by calling the pinephone from another phone, answering the call, and after 5 or 10 seconds I hung up the call on the calling phone.

I'm running a fresh install of pmOS 21.12 with sxmo de sway 1.6.1 on a pinephone.

My 2 bluetooth keyboards and 1 bluetooth mouse all paired fine via the sxmo bluetooth menu. However, only 1 of the 3 can be connected to the pinephone at any given time. The only way for another device to connect (despite being paired already) is to turn off or disconnect the currently connected device.

Thanks, that worked. There was nothing else in my profile to set svkbd-mobintl; maybe it defaults to that if $KEYBOARD doesn't exist.

It works fine in sxmo 1.6.1.

I did a fresh install of postmarketOS 21.12 with SXMO 1.6.1 de sway.

I add the following to my ~/.profile:

export KEYBOARD="wvkbd-mobintl -H 350 -l full,special"

When I rebooted, I wasn't able to bring up the soft keyboard. The KEYBOARD environment variable was set to svkbd-mobintl.

Am I doing something wrong?

pipewire sounds like a good idea as a general direction.

My cursory glance at wys seemed like it is a daemon that tries to implement audio routing policy according to some config files. I didn't see example configs though.

callaudiod seems to have a similar goal, but also has the CLI/dbus interfaces to allow a little more flexibility.

Something I appreciate about sxmo is that the policy code is very explicit, not difficult to find, and often easily overridable without ever touching a compiler via the hooks or worst-case just modifying a script or two. I don't see that flexibility with either of these daemons: they seem to mix the mechanism and policy together and hide it in a C program.

I haven't spent the time needed to understand all the audio stuff, but it seems like Megi's C code is accessing some Alsa APIs that could also be accessed via a script, or at most a small C program with the barest of mechanism that could be controlled from scripts implementing the policy. Perhaps going forward the scripts would do it the pipewire way, whatever that is.

An additional related ticket is here: https://todo.sr.ht/~mil/sxmo-tickets/414

Adding the following line to /etc/doas.d/sxmo.conf seems to fix the problem:

permit nopass :wheel as root cmd setup-timezone

On a fresh install of pmOS edge with sxmo, then immediately upgraded to swmo 1.6.0, I tried to change the timezone from the config menu. I got this error:

doas: Operation not permitted

The timezone does not appear to be updated.

Thanks for the tip, that helped me dig deeper. I started alsamixer and watched it while starting a call. alsamixer showed the headphone volume immediately set to 16% which seems to roughly match what sxmo_megiaudioroute is doing. However, choosing the Volume Up and Volume Down entries in the call menu didn't seem to affect the headphone volume as shown in alsamixer, nor in what I can hear in the headphones. Also, the volume up/down gestures don't change the headphone volume in the call either. So there seems to be some sort of problem controlling the headphone volume during the call.