Difference between revisions of "Talk:Udev"

From ArchWiki
Jump to: navigation, search
m (Use of 'uaccess' instead of GROUP and MODE?: forgot to sign)
m (Marking talk section on Hot Plug for deletion and already added feedback to main page.)
 
(18 intermediate revisions by 6 users not shown)
Line 2: Line 2:
 
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:
 
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"
 
  "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.
+
everything worked fine. Not sure what the root of the issue is, but this rule makes the usbtiny programer unusable. -- [[User:Ssalenik|Ssalenik]] ([[User talk:Ssalenik|talk]]) 04:09, 6 March 2012‎
 
+
== umask fails to apply to vfat/ntfs partitions ==
+
Has anyone else found that umask settings do not apply as they should?  Setting umask to 002 or 0002 results in all files having the executable bit enabled. However, if I manually set the fmask/dmask values (ex: fmask=113,dmask=002) it works fine. --[[User:Thayer|thayer]] 16:40, 5 May 2010 (EDT)
+
 
+
== Extract the UDisks into new article ==
+
 
+
As UDev is more generic than just disk mounting subsystem, I propose to extract the UDisks part into its own page to keep things simple and clear. [[User:Lux|Lux]] ([[User talk:Lux|talk]]) 19:32, 27 July 2012 (UTC)
+
 
+
:: Agreed 100%. [[User:Sambul13|Sambul13]] 09.40, 03 September 2012 (UTC)
+
  
 
== About udev rules ==
 
== About udev rules ==
Line 37: Line 28:
 
* http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
 
* http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
 
[[User:Lekensteyn|Lekensteyn]] ([[User talk:Lekensteyn|talk]]) 10:16, 6 June 2013 (UTC)
 
[[User:Lekensteyn|Lekensteyn]] ([[User talk:Lekensteyn|talk]]) 10:16, 6 June 2013 (UTC)
 +
 +
== Printers ==
 +
 +
[[Udev#Printers]]:
 +
 +
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 {{Pkg|system-config-printer}} handle this automatically? If so, a tip could be added. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:38, 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
 +
XAUTHORITY=/run/user/1000/gdm/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 14:01, 19 May 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]

and

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"

References:

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

Printers

Udev#Printers:

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)

Additional detail on "Execute on VGA cable plug"

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
XAUTHORITY=/run/user/1000/gdm/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. 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. -- 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. -- 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 /proc/foo/environ) and passes it to arandr. Would take some experimenting to get it universally working, but should be good to have. -- 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. Netadmin (talk) 14:00, 19 May 2016 (UTC)