| Both sides previous revision Previous revision Next revision | Previous revision |
| udev_rules [2022/01/27 12:29] – [Troubleshooting] nadenislamarre | udev_rules [2025/02/19 20:07] (current) – [Run a script when a device is connected] nadenislamarre |
|---|
| In a nutshell, udev rules do always have two major parts: | In a nutshell, udev rules do always have two major parts: |
| * **Matches** ("If the condition(s) matches"...). The operator for matches are ''=='' and ''!='' | * **Matches** ("If the condition(s) matches"...). The operator for matches are ''=='' and ''!='' |
| * **Actions** (..."then do this!"). The operator for actions is: ''='' | * **Actions** (..."then do this!"). The operator for actions is: ''='' |
| | |
| | ===== Useful links ===== |
| | |
| | Shamelessly referencing the Arch wiki here, although Arch uses system.d for udev a lot of it still applies to Batocera: |
| | * [[https://wiki.archlinux.org/title/Udev|Arch Wiki's udev page]] |
| | * [[https://man.archlinux.org/man/udev.7.en|Arch's manual for udev]] |
| | * [[http://www.reactivated.net/writing_udev_rules.html|udev rules system syntax, how to write "rules" files]] |
| | * [[http://www.reactivated.net/writing_udev_rules.html#example-printer|From that same page, reference rules file examples]] |
| |
| ===== udev rules in Batocera ===== | ===== udev rules in Batocera ===== |
| |
| Batocera supports booting up and event udev rules like with any ordinary operating system. These can be manipulated in the usual ''/etc/udev/rules.d/'' directory. However, changes cannot be permanently stored there due to Batocera's filesystem ([[:modify_the_system_while_it_s_running|overlays]] can be used, but are forgotten between upgrades). | Batocera supports booting up and event udev rules like with any ordinary operating system. These can be manipulated in the usual ''/etc/udev/rules.d/'' directory. However, changes cannot be permanently stored there due to Batocera's filesystem ([[:modify_the_system_while_it_s_running|overlays]] can be used, but are forgotten between upgrades). |
| |
| But if you only need event udev rules, then the ''/userdata/system/udev/rules.d/'' path can be used instead. The path must be initially created manually. | |
| |
| For example, if you wanted to enable the [[https://wiki.dolphin-emu.org/index.php?title=Bluetooth_Passthrough|Bluetooth passthrough udev rule of Dolphin]] for your own Bluetooth dongle (list of compatible adapters **for Dolphin, not necessarily [[hardware:compatible_dongle_list|Batocera]]** is [[https://wiki.dolphin-emu.org/index.php?title=Bluetooth_Passthrough#Adapter_test_results|further down that page]]), you would use this file: | For example, if you wanted to enable the [[https://wiki.dolphin-emu.org/index.php?title=Bluetooth_Passthrough|Bluetooth passthrough udev rule of Dolphin]] for your own Bluetooth dongle (list of compatible adapters **for Dolphin, not necessarily [[hardware:compatible_dongle_list|Batocera]]** is [[https://wiki.dolphin-emu.org/index.php?title=Bluetooth_Passthrough#Adapter_test_results|further down that page]]), you would use this file: |
| <code - 52-dolphin.rules> | <code - 52-dolphin.rules> |
| SUBSYSTEM=="usb", ATTRS{idVendor}=="YOURVID", ATTRS{idProduct}=="YOURPID", TAG+="uaccess" | SUBSYSTEM=="usb", ATTRS{idVendor}=="YOURVID", ATTRS{idProduct}=="YOURPID", TAG+="uaccess" |
| | ACTION=="add", ENV{PRODUCT}=="57e/305/100", RUN+="/bin/sh -c 'echo -n $kernel > /sys/bus/usb/drivers/btusb/unbind'" |
| </code> | </code> |
| |
| Replace the values ''YOURVID'' and ''YOURPID'' according to your specific device found in the list mentioned above. Then save it and copy it to ''/userdata/system/udev/rules.d/52-dolphin.rules'' and reboot Batocera. | Where the values ''YOURVID'' and ''YOURPID'' are replaced according to your specific device found in the list mentioned above. Then save it and copy it to ''/etc/udev/rules.d/52-dolphin.rules'', run batocera-save-overlay and reboot Batocera. |
| |
| <WRAP center round tip> | <WRAP center round tip> |
| If you need something activated earlier in the boot process or something more intimate to the system, you can instead use [[:launch_a_script#launching_a_script_early_in_the_boot_process|boot scripts]]. | If you need something activated earlier in the boot process or something more intimate to the system, you can instead use [[:launch_a_script#launching_a_script_early_in_the_boot_process|boot scripts]]. |
| </WRAP> | </WRAP> |
| | |
| | Udev doesn't strictly need the VID or PID to identify a device, its name attribute can be used instead (however this is more susceptible to being applied to the similar devices connected). |
| |
| ==== Deeper explanation of udev rules ==== | ==== Deeper explanation of udev rules ==== |
| Once Batocera has booted you can view the existing udev rules for your system in ''/etc/udev/rules.d/''. You can do this from the file manager (''[F1]'' on the system list) and going up one level, or [[:access_the_batocera_via_ssh|via SSH]]. You cannot access this location from the network share, as it is outside of the userdata partition. | Once Batocera has booted you can view the existing udev rules for your system in ''/etc/udev/rules.d/''. You can do this from the file manager (''[F1]'' on the system list) and going up one level, or [[:access_the_batocera_via_ssh|via SSH]]. You cannot access this location from the network share, as it is outside of the userdata partition. |
| |
| ==== Troubleshooting ==== | ===== Create your own udev rule ===== |
| |
| If you find that your udev rule isn't working after reboot for any reason, you can alternatively try putting your ''*.rules'' file directly into ''/etc/udev/rules.d/'' and running ''batocera-save-overlay'' afterward. This will call it slightly earlier in the boot process. Remember: Everything saved to the boot partition via ''batocera-save-overlay'' will get lost after updating Batocera to a new version. | In order to create a udev rule either its name (or other uniquely identifiable attribute) or the VID and PID need to be discovered. |
| | |
| | - [[:access_the_batocera_via_ssh|Connect to Batocera via SSH]] |
| | - Run the list command for the device in question: |
| | * For input devices, this can be achieved with ''evtest'' or for a more systematic approach, ''cat /proc/bus/input/devices'' |
| | * For USB devices in general: ''lsusb'' |
| | * For devices in general (or if you don't know what subsystem it uses), search through the ''/dev/'' folder in root: ''ls /dev'' and then ''ls /dev/<subsystem>'' |
| | - Once the device's path is discovered, run the following command to list all of its accessible attributes: <code bash> |
| | sudo udevadm info --query all --path /sys/block/sdb/sdb5/ --attribute-walk |
| | </code> where ''/sys/block/sdb/sdb5/'' is the path the device is using, where-ever that may be. |
| | - Make an appropriate ''##-<any-name-you-want>.rules'' where ''##'' is a number (udev will apply the rules in this specified order, most of the time this can be 99 with no issues) |
| | - If not making a boot udev rule, it can be tested immediately by reloading the udev service: <code bash>udevadm control --reload-rules && udevadm trigger</code> |
| | * Once this is done, run the following to test if the rule has been parsed and applied correctly: <code bash>udevadm info -q all -n /dev/<subsystem>/<device></code> |
| | |
| | ==== Transform a keyboard into a pad ==== |
| |
| === Transform a keyboard to a pad === | The keyboard can be identified with ''evtest'' (in this example, ''event3''): |
| * Unordered List Itemconnect as ssh | |
| * identify your keyboard : run evtest. (in my case, this is the event3) | |
| |
| # evtest | # evtest |
| Select the device event number [0-13]: | Select the device event number [0-13]: |
| |
| * create an udev rule to set this event as a joystick. | Create a udev rule to set this event as a joystick. This can be achieved with this one-line command (where ''AT Translated Set 2 keyboard'' is the name of your keyboard): |
| |
| echo 'SUBSYSTEM=="input", ATTRS{name}=="AT Translated Set 2 keyboard", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1", ENV{ID_INPUT_KEYBOARD}="0"' > /etc/udev/rules.d/99-custom | echo 'SUBSYSTEM=="input", ATTRS{name}=="AT Translated Set 2 keyboard", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1", ENV{ID_INPUT_KEYBOARD}="0"' > /etc/udev/rules.d/99-custom.rules |
| | |
| * reread rules | To make sure it's work, reload the rules and check if the flag is present: |
| |
| udevadm control --reload-rules && udevadm trigger | udevadm control --reload-rules && udevadm trigger |
| | udevadm info -q all -n /dev/input/event3 |
| | |
| | ==== Run a script when a device is connected ==== |
| |
| * check the flag is present | Identify the name attribute of the device. Download this file and then replace the ''<>'' respectively: |
| | |
| | <file - 99-run-script-on-connect.rules> |
| | SUBSYSTEM=="input", ATTRS{name}=="<name of device>", MODE="0666", RUN+="<path/to/script.sh>" |
| | </file> |
| | |
| | Save the file to ''/etc/udev/rules.d'' and run batocera-save-overlay. |
| | |
| | ==== Troubleshooting ==== |
| | |
| | If you find that your udev rule isn't working after reboot for any reason, you can alternatively try putting your ''*.rules'' file directly into ''/etc/udev/rules.d/'' and running ''batocera-save-overlay'' afterward. This will call it slightly earlier in the boot process. Remember: Everything saved to the boot partition via ''batocera-save-overlay'' will get lost after updating Batocera to a new version. |
| |
| udevadm info -q all -n /dev/input/event3 | |