Differences

This shows you the differences between two versions of the page.

--- udev_rules [2021/10/05 05:01] – added troubleshooting atari
+++ udev_rules [2025/02/19 20:07] (current) – [Run a script when a device is connected] nadenislamarre
@@ Line 1: / Line 1: @@
-<WRAP center round todo 60%>
+====== udev Rules ======
-Under construction, but this needs to be here as it's mentioned literally //no where else//.
-</WRAP>
-====== udev Rules in Batocera ======
+[[https://en.wikipedia.org/wiki/Udev|udev]] stands for //userspace ''/dev''// and is a device manager for the Linux kernel. The ''/dev'' path is ordinarily where device information is accessed from, //udev rules// allow you to alter this information in a predictable and permanent manner. For example, what drivers to use/blacklist for a specific device being plugged in.
-Batocera supports the use of udev rules just like any other ordinary Linux-based operating system, however the path to use it is different from most. You can transfer your udev rules over to ''/userdata/system/udev/rules.d/'' and they will be enabled once Batocera has finished booting.
+udev rules are checked when:
+  - Booting up, all udev rules are parsed and a rules database is built in memory
+  - When an event happens, it checks its rule database and performs the appropriate actions.
-If you need something activated earlier in the boot process or something more intimate to the system, you can instead opt to use [[:launch_a_script#launching_a_script_early_in_the_boot_process|boot scripts]].
+In a nutshell, udev rules do always have two major parts:
+  * **Matches** ("If the condition(s) matches"...). The operator for matches are ''=='' and ''!=''
+  * **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 =====
+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).
 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:
@@ Line 13: / Line 27: @@
 <code - 52-dolphin.rules>
 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>
-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.
-===== Viewing and editing pre-existing udev rules =====
+<WRAP center round tip>
+If the udev rule does not function in this path, then it is a booting up udev rule and must use the aforementioned ''/etc/udev/rules.d/'' directory.
+</WRAP>
+<WRAP center round info>
+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>
+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 ====
+As an example, let's take the udev rule ''52-dolphin.rules'' from above to dive a little deeper into udev rules:
+''SUBSYSTEM'', ''ATTRS{idVendor}'' and ''ATTRS{idProduct}'' are all variables that do all have a ''=='' between them and their assigned values. This means they are all //matches// (conditions). On the other hand, the last variable ''TAG'' does have a ''+='', which adds itself to any other TAG action being executed on this specific event (e.g. by an additional udev rule matching the same event).
+This udev rule can be read as follows:
+//If the detected device is a USB device with the vendor ID 'YOURVID' and the product ID 'YOURPID', then, in addition to any other TAG action on this specific event, tag the device with 'uaccess'// (which provides access to the ''/dev/'' file for the logged in user (in case of Batocera, mostly **root** user)).
+==== Viewing and editing pre-existing 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.
-===== Troubleshooting =====
+===== Create your own udev rule =====
+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 ====
+The keyboard can be identified with ''evtest'' (in this example, ''event3''):
+  # evtest
+  No device specified, trying to scan all of /dev/input/event*
+  Available devices:
+  /dev/input/event0:	Lid Switch
+  /dev/input/event1:	Sleep Button
+  /dev/input/event2:	Power Button
+  /dev/input/event3:	AT Translated Set 2 keyboard
+  /dev/input/event4:	Video Bus
+  /dev/input/event5:	Video Bus
+  /dev/input/event6:	HDA Intel PCH Headphone
+  /dev/input/event7:	HDA Intel HDMI HDMI/DP,pcm=3
+  /dev/input/event8:	HDA Intel HDMI HDMI/DP,pcm=7
+  /dev/input/event9:	HDA Intel HDMI HDMI/DP,pcm=8
+  /dev/input/event10:	FocalTechPS/2 FocalTech Touchpad
+  /dev/input/event11:	Asus WMI hotkeys
+  /dev/input/event12:	8Bitdo  8BitDo N30 Pro 2
+  /dev/input/event13:	USB2.0 HD UVC WebCam: USB2.0 HD
+  Select the device event number [0-13]:
+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.rules
+To make sure it's work, reload the rules and check if the flag is present:
+  udevadm control --reload-rules && udevadm trigger
+  udevadm info -q all -n /dev/input/event3
+==== Run a script when a device is connected ====
+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.
+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.