I recommend you look at ~/.config/sxmo/sway for keybindings. Or https://git.sr.ht/~mil/sxmo-dwm/tree/master/item/config.def.h if you're on the dwm version. Super/GUI/WIN+d on sway, Super/GUI/WIN+p on dwm.

I tried out ~mungfusensei's sxmo_modemaudio.sh, and got it working after changing _card and _sink to grep -v out the _hdmi entries, and changing "VoiceCall" to "Voice Call". (I'm using pipewire, if that's relevant).

It seemed to work fine for receiving a call, and switching back/forth between speaker phone/earpiece, but when I plugged in headphones, nothing worked any more. (it should be noted that callaudiod was still running in the background, just not sure what exactly it does anyway.)

Pretty much everything in this list is fixed, minus Megapixels. Sound can be made to work but has to be done at the kernel/distro level, easy for a user to fix themselves though, and out of SXMO's hands.

Fixed with https://git.sr.ht/~mil/sxmo-utils/commit/e991ce6

I ran into this a lot while trying to rewrite sxmo_modemaudio.sh to use pactl instead of callaudiod. Here's my version for reference. It's still WIP, but I was able to get rid of that problem.

https://termbin.com/1c59

Tweaking the volume made sure that the sink/card was not suspended, which allowed the switch to happen. It's probably not the right way to fix it, but it works.

EDIT: I should note that I did this to solve both "failed to setup" and "failed to reset" errors, not sure if it'd solve your exact issue with the sequence you stated.

While we're at it, if the status gets too long, it stops displaying entirely. Wonder if it might be worth applying the notitle patch for dwm to free up some space, since it's basically useless to have window titles while undocked at least (I don't even have them on my desktop).

http://dwm.suckless.org/patches/notitle/

On top of that, might be worth it to have the lock state displayed as icons rather than text, to free up even more real estate for status icons.

I've gotten the dwm version working smoothly on the pro, but there were some hiccups involved which raise some questions as to how it should be patched.

1. The pinephone pro's touchscreen xinput ID is 7, not 8. This is a simple fix, but could there be a way of automating this? Do touchscreens have some common identifier somewhere that could be found to create a script? This might help with other devices if such a common factor could be found. If the SXMO_SCREEN is set to 8, that's actually the power button, so when the user locks, sxmo turns off the power button, so they can't unlock.

2. The primary monitor on the pro is DP-1, not DSI-1. This breaks the orientation on sxmo_hook_lisgdstart.sh. My current fix is just adding xrandr --output DSI-1 --primary in the dwm section of sxmo_hook_start.sh. So we could have a custom start hook just for the pinephonepro, or we could add another variable in deviceprofiles like $SXMO_MONITOR, and have sxmo_hook_start.sh run xrandr --output $SXMO_MONITOR --primary, which I don't think would break anything?

3. Battery monitoring on the pro is a nightmare, with 3-4 different things under /sys/class/power_supply/ that create conflicting information. At minimum, the battery itself is always shown as charging, so the default status is only good for percentage, not state. I'm still trying to pick it apart, and have state working, but not in a way that easily fits in with the way that the battery monitoring works now. Basically just checking /sys/class/rk818-usb/present and setting status with a case statement. Could use more brainpower here.

This ticket is just a measure twice/cut once conversation before I try submitting a patch.

Ran sxmo_build yesterday, cleared up audio issues with lingering pipewire.conf files, and added the sleep 2 to sxmo_hook_start.sh.

Opening the appmenu via gesture, selecting Reboot or Poweroff simply kills off running daemons, and doesn't actually reboot/poweroff. You then have to open the menu via volup, and repeat the process for it to actually occur. However, if you open the menu using volup, selecting reboot/poweroff works just fine.

Logging out works from either the gesture or button. However, logging out will not start superd when it logs back in. You have to log out a second time, and then superd will start upon the 2nd login.

~phartman Sound works on the PPP, if your ucm files are working properly, and you're using the git version of sxmo instead of 1.8.2. The alsa ucm files don't have clean little playback switches for certain things like the earpiece, so the 1.8.2 audio scripts can never actually be satisfied, even with a device profile fully filled out. It works fine under pipewire/pulse, except for callaudiod, which might be a separate issue entirely and isn't a universal problem.

Having dealt with trying to get audio on my PPPro working for the last couple weeks, some things should be noted here, as they may not be sxmo-specific problems.

On pmOS, the ucm files aren't properly loaded due to either the card name not being properly recognized, or the files being misnamed. I'm guessing it's the first. If you are having audio troubles with your Pro, try this.

strace alsaucm -c hw:0 set _verb HiFi 2>&1 | grep -e "alsa/ucm.*ENOENT"

If your ucm files are named correctly, this should output nothing. If they are misnamed, this will tell you what files it's actually looking for. Just rename your /usr/share/alsa/ucm2/conf.d/simple-card/PinePhonePro.conf as necessary, and audio will work fine with pipewire etc. The only issue after that is callaudiod not switching profiles. Calls work fine if you manually switch to the VoiceCall profile (Phone call in pavucontrol).

Just for clarity, this is not an sxmo issue, but it does muddy the picture when it comes to dealing with sxmo audio issues, so it's best that users are aware of it.