I guess the following code doesn't cover all cases, but I do think it would be helpful in multiple cases.
#!/bin/sh
# deviceprofile generator for Swmo
# SPDX-License-Identifier: AGPL-3.0-only
# Copyright 2023 Sxmo Contributors
CODENAME=$(cat /proc/device-tree/compatible | grep -oP '[^�]*' | head -n 1)
FILENAME=sxmo_deviceprofile_$CODENAME.sh
YEAR=$(date +%Y)
JSON=$(swaymsg -t get_inputs)
# /questions/48005870/iterate-over-json-with-jq
# identifier of type touch
while read -r type identifier; do
if [[ ${type} = 'touch' ]]
then
TOUCH=${identifier}
fi
done< <(echo "${JSON}" | jq --raw-output '.[] | "\(.type) \(.identifier)"')
# identifier of gpio
while read -r name identifier; do
if [[ ${name} = 'gpio-keys' ]]
then
GPIO=${identifier}
fi
done< <(echo "${JSON}" | jq --raw-output '.[] | "\(.name) \(.identifier)"')
# identifier of keys volume
while read -r identifier; do
if [[ ${identifier} = *'resin'* ]]
then
RESIN=${identifier}
fi
done< <(echo "${JSON}" | jq --raw-output '.[] | "\(.identifier)"')
# identifier of key power
while read -r identifier; do
if [[ ${identifier} = *'pwrkey'* ]]
then
PWRKEY=${identifier}
fi
done< <(echo "${JSON}" | jq --raw-output '.[] | "\(.identifier)"')
echo "#!/bin/sh
# auto-generated deviceprofile for $CODENAME
# SPDX-License-Identifier: AGPL-3.0-only
# Copyright $YEAR Sxmo Contributors
export SXMO_DISABLE_LEDS="1"
export SXMO_MONITOR="$TOUCH"
export SXMO_POWER_BUTTON="$PWRKEY"
export SXMO_VOLUME_BUTTON="$GPIO $RESIN"
export SXMO_SWAY_SCALE="2"
#export SXMO_VIBRATE_DEV=""
" > $FILENAME
cat << EOF
#!/bin/sh
# auto-generated deviceprofile for $CODENAME
# SPDX-License-Identifier: AGPL-3.0-only
# Copyright $YEAR Sxmo Contributors
export SXMO_DISABLE_LEDS="1"
export SXMO_MONITOR="$TOUCH"
export SXMO_POWER_BUTTON="$PWRKEY"
export SXMO_VOLUME_BUTTON="$GPIO $RESIN"
export SXMO_SWAY_SCALE="2"
#export SXMO_VIBRATE_DEV=""
EOF
I meant deviceprofile
#!/bin/sh # deviceprofile generator for Swmo # SPDX-License-Identifier: AGPL-3.0-only # Copyright 2023 Sxmo Contributors CODENAME=$(cat /proc/device-tree/compatible | grep -oP '[^�]*' | head -n 1) FILENAME=sxmo_deviceprofile_$CODENAME.sh YEAR=$(date +%Y) JSON=$(swaymsg -t get_inputs) # /questions/48005870/iterate-over-json-with-jq while read -r identifier name type; do # identifier of keys volume if [[ ${identifier} = *'resin'* ]] then RESIN=${identifier} fi # identifier of key power if [[ ${identifier} = *'pwrkey'* ]] then PWRKEY=${identifier} fi # identifier of gpio if [[ ${name} = 'gpio-keys' ]] then GPIO=${identifier} fi # identifier of type touch if [[ ${type} = 'touch' ]] then TOUCH=${identifier} fi done< <(echo "${JSON}" | jq --raw-output '.[] | "\(.identifier) \(.name) \(.type)"') echo "#!/bin/sh # auto-generated deviceprofile for $CODENAME # SPDX-License-Identifier: AGPL-3.0-only # Copyright $YEAR Sxmo Contributors export SXMO_DISABLE_LEDS="1" export SXMO_MONITOR="$TOUCH" export SXMO_POWER_BUTTON="$PWRKEY" export SXMO_VOLUME_BUTTON="$GPIO $RESIN" export SXMO_SWAY_SCALE="2" #export SXMO_VIBRATE_DEV="" " > $FILENAME cat << EOF #!/bin/sh # auto-generated deviceprofile for $CODENAME # SPDX-License-Identifier: AGPL-3.0-only # Copyright $YEAR Sxmo Contributors export SXMO_DISABLE_LEDS="1" export SXMO_MONITOR="$TOUCH" export SXMO_POWER_BUTTON="$PWRKEY" export SXMO_VOLUME_BUTTON="$GPIO $RESIN" export SXMO_SWAY_SCALE="2" #export SXMO_VIBRATE_DEV="" EOF
good idea!
You can use https://www.shellcheck.net/ to write shell scripts that are more portable. Note that some of those warnings are false-positives.
There's also https://github.com/dylanaraps/pure-sh-bible
But it doesn't seem to be useful for multiple devices, in example, this pinephone-pro:
0:0:wlr_virtual_keyboard_v1 1:1:gpio-keys 1:1:gpio-key-ri 1046:1158:Goodix_Capacitive_TouchScreen 1046:1158:Goodix_Capacitive_TouchScreen 1:1:adc-keys
pwr? resin? over-automation indeed
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.
noneofyourbusiness, please help me. I'm a not a professional.
aren, even though devices are more powerful now, I'm not in favor of a daemon, unless it terminate itself once it gets an indication that hardware keys are working.
I'm not an expert.
kohn: (tl;dr) in short, I think automating this problem is too difficult and that we should give this endeavor up.
Additionally
- which kind of input is it?
- which chip is connected to which buttons/screens/etc? Possibly unused?
- how can this be automated?
Definitely out of scope for sxmo, postmarketos, and I think even the linux kernel project.
A device designer may connect a chip in any way they like.
A kernel device driver usually only knows what it's told, which also varies between devices. It doesn't help at all when device drivers are written under NDA: https://lwn.net/Articles/203562/ - a topic with a lot of history as well
This is really a utility script.
What would be the proper place for it?
Perhaps we should upload it to pmOS or SXMO documentation.
There's user scripts https://sr.ht/~anjan/sxmo-userscripts/
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).
This would ony work when SXMO is installed with Wayland, does not work if it's installed from postmarketos-ui-sxmo package (at least on motorola-harpia), since it installs with X (sxmo+dwm etc.). Would there be a way of detecting keypresses in order to get the volume buttons right etc., if someone wrote an interactive script?
I didn't take care for X11. I should add this code:
case $XDG_SESSION_TYPE in x11) # I didn't find the X11 command # https://git.sr.ht/~mil/sxmo-utils/tree/master/item/scripts/deviceprofiles/README.md # Maybe i3-msg -t get_outputs? wayland) # swaymsg -t get_inputs esac
Would there be a way of detecting keypresses in order to get the volume buttons right etc., if someone wrote an interactive script?
An interactive script is a good idea! I think an interactive script is possible using
xev
.