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.
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.
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?
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.
My two cents based on working on the pinenote:
Re: (1) - I looked into this when working on the pinenote and I was not able to come up with a simple solution to automatically detect input ids (as we can in sway). Fortunately, these ids are static, so we can just hard code them. If someone has a better solution, then that'd be fantastic.
Re: (2) - I think you can rename the monitor in xorg.conf. Not ideal though. But that's what we were doing before.
Not sure about batteries.
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).
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.
The first 2 are fixed with the latest patch in git head. Let's start a new thread for #3.