~mil/sxmo-tickets#581: 
Auto generate deviceinfo

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
Status
REPORTED
Submitter
~kohn
Assigned to
No-one
Submitted
8 months ago
Updated
8 months ago
Labels
No labels applied.

~kohn 8 months ago

I meant deviceprofile

~kohn 8 months ago*

#!/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

~noneofyourbusiness 8 months ago

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

~noneofyourbusiness 8 months ago

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

~aren 8 months ago

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.

~kohn 8 months ago

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.

~noneofyourbusiness 8 months ago

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

~kohn 8 months ago

This is really a utility script.

What would be the proper place for it?

Perhaps we should upload it to pmOS or SXMO documentation.

~noneofyourbusiness 8 months ago

~aren 8 months ago

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

~pavezzi 8 months ago

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?

~kohn 8 months ago*

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.

Register here or Log in to comment, or comment via email.