Difference between revisions of "Talk:Udev"

From ArchWiki
Jump to: navigation, search
m (Marking talk section on Hot Plug for deletion and already added feedback to main page.)
m (Additional detail on "Execute on VGA cable plug": removed closed discussion)
Line 38: Line 38:
:It might, unfortunately its {{Pkg|gtk3}} dependency discouraged me from even trying... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:01, 28 June 2014 (UTC)
:It might, unfortunately its {{Pkg|gtk3}} dependency discouraged me from even trying... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:01, 28 June 2014 (UTC)
== <s>Additional detail on "Execute on VGA cable plug"</s> ==
Not sure if it belongs in this wiki, but worth noting in the hot plug example that the Xauthority may be located elsewhere based on display manager.
This is the example:
KERNEL=="card0", SUBSYSTEM=="drm", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/arandr"
If you have GDM and you check the Xauthority location as follows:
$ env | grep XAUTHORITY
You will see the file is not in a home directory and you need to tweak the ENV{XAUTHORITY} accordingly.
Not sure if this bit of information is useful in the wiki or consider overly specific for this use case. [[User:Netadmin|Netadmin]] ([[User talk:Netadmin|talk]]) 16:22, 10 May 2016 (UTC)
:Well this is another example why you should never hardcode [[Xorg]] variables. I agree it should be fixed. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:27, 10 May 2016 (UTC)
::In this rule the hard-coded value is ''assigned'' to ENV{XAUTHORITY}. In any case, you can't make the udev rule work without hardcoding, because udev does not have access to the environment of the ''currently active'' session. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:46, 10 May 2016 (UTC)
:::Well, you could run a wrapper script in the udev rule, which retrieves the XAUTHORITY env (e.g from {{ic|/proc/foo/environ}}) and passes it to arandr. Would take some experimenting to get it universally working, but should be good to have. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:12, 10 May 2016 (UTC)
: I updated the Hot Plug section to note that .Xauthority may be located in different locations based on the display manager. [[User:Netadmin|Netadmin]] ([[User talk:Netadmin|talk]]) 14:00, 19 May 2016 (UTC)

Latest revision as of 11:18, 4 June 2016

usbtiny extra udev rule?

In the udev rules for usbtiny, there are 2 rules listed. Howver, adding the second one to my udev rules resulted in me not an "rc=-1" communication error when I tried to use my usbtiny. When I commented out this rule:

"SBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"

everything worked fine. Not sure what the root of the issue is, but this rule makes the usbtiny programer unusable. -- Ssalenik (talk) 04:09, 6 March 2012‎

About udev rules

udevadm info -a -n [device name]


udevadm info -a -p $(udevadm info -q path -n [device name])

gives the same output but the latter is recommended by some Khampf (talk) 20:57, 5 February 2013 (UTC)

Use of 'uaccess' instead of GROUP and MODE?

Bug openobex - relies on non-existing group plugdev, conflict with systemd made me rethink the rules I have been using for Logitech_Unifying_Receiver.

Currently, the following rule is taught to the user:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"

What about changing it to:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", TAG+="uaccess"

As a developer note, Ubuntu versions before 13.04 Raring needs TAG+="udev-acl" instead of uaccess. For compatibility with modern and legacy systems:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", TAG+="uaccess", TAG+="udev-acl"


Lekensteyn (talk) 10:16, 6 June 2013 (UTC)



If you use multiple printers, /dev/lp[0-9] devices will be assigned randomly on boot, which will break e.g. CUPS configuration.

I don't use multiple printers, but doesn't system-config-printer handle this automatically? If so, a tip could be added. --Alad (talk) 08:38, 28 June 2014 (UTC)

It might, unfortunately its gtk3 dependency discouraged me from even trying... -- Lahwaacz (talk) 09:01, 28 June 2014 (UTC)