This will not perform all actions in your new rules but it will however process symlink rules on existing devices which might come in handy if you are unable to load them otherwise
Your tests show that 'udevadm test' processes also the rules with a MODE change on existing devices.
I don't know why the rules with a MODE change are not applied just after the creation of the nodes, but seem to require a re-parsing of the rules after their creation.
Nevertheless you now have another way to neutralize the bogus nodes by running the 'udevadm test' commands at the end of the starting sequence, and so forcing the MODE change then. Maybe 'udevadm trigger' could be used too for that.
About the MODE, I noticed a weird behavior, both with the = or := operator. I changed the RUN rule with MODE="0000" and plugged the mouse. (MODE:="0000" is the same)
This is what happen:
# cd /dev/input
# ls -l1 |grep 'event13\|js'
c---rw----+ 1 root root 13, 77 15 mag 23.28 event13
c---rw----+ 1 root root 13, 0 15 mag 23.28 js0
# udevadm test $(udevadm info -q path -n /dev/input/event13 ) &>/dev/null
# ls -l1 |grep 'event13\|js'
c---------+ 1 root root 13, 77 15 mag 23.29 event13
c---rw----+ 1 root root 13, 0 15 mag 23.28 js0
# udevadm test $(udevadm info -q path -n /dev/input/js0 ) &>/dev/null
# ls -l1 |grep 'event13\|js'
c---------+ 1 root root 13, 77 15 mag 23.29 event13
c---------+ 1 root root 13, 0 15 mag 23.30 js0
#
It seems that while testing it notices the wrong mode setting and it fixes it...
]]>Finally, I wanted to add a clarification about the use of the '*' character in wildcard patterns inside a udev rule:
udev rules understand and use shell globbing patterns, not regular expression patterns.
So "event[0-9]*" doesn't mean "event" followed by zero or more digit characters, as in a regular expression;
but it means "event" followed by one digit character, followed by zero or more any characters, because it is the '*' of the shell globbing pattern, as in a path expansion.
Consequently the value "event1abcd" will match, and "event" will not match (it must be followed by one digit), as opposed to the same pattern using a regular expression where "event1abcd" will not match, and "event" will match.
I wanted to precise that, in case you made this error, as I also did, when writing your udev rules.
Greetings.
Here is the fixed rule:
KERNEL=="event[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_event}="ONE"
KERNEL=="event[0-9]*", ENV{.bogus_mouse_event}=="ONE", ATTRS{manufacturer}=="A4TECH", ATTRS{idProduct}=="9090", ENV{.bogus_mouse_event}="TWO"
KERNEL=="event[0-9]*", ENV{.bogus_mouse_event}=="TWO", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", RUN+="/usr/bin/rm %N"
KERNEL=="js[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_js}="ONE"
KERNEL=="js[0-9]*", ENV{.bogus_mouse_js}=="ONE", ATTRS{manufacturer}=="A4TECH", ATTRS{idProduct}=="9090", ENV{.bogus_mouse_js}="TWO"
KERNEL=="js[0-9]*", ENV{.bogus_mouse_js}=="TWO", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", RUN+="/usr/bin/rm %N"
It gets the A4TECH usb device 9090 bogus nodes and deletes them.
I think I will update the wiki eventually: the linked udev page about writing rules is outdated and there is no explanation how to make rules to match a node using multiple parents of it.
]]>I will look again to that issue tomorrow, I can't at the moment...
]]>KERNEL=="event[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_event}="ONE"
KERNEL=="event[0-9]*", ENV{.bogus_mouse_event}="ONE", ATTRS{manufacturer}=="A4TECH", ATTRS{idProduct}=="9090", ENV{.bogus_mouse_event}="TWO"
KERNEL=="event[0-9]*", ENV{.bogus_mouse_event}="TWO", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", RUN+="/usr/bin/rm %N"
KERNEL=="js[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_js}="ONE"
KERNEL=="js[0-9]*", ENV{.bogus_mouse_js}="ONE", ATTRS{manufacturer}=="A4TECH", ATTRS{idProduct}=="9090", ENV{.bogus_mouse_js}="TWO"
KERNEL=="js[0-9]*", ENV{.bogus_mouse_js}="TWO", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", RUN+="/usr/bin/rm %N"
But the question still stand, what can possibly change the permission after udev?
]]>But the mode is set up to 040 instead of 000! The filename is 99-something.rules should it should be called last.
Besides the udevadm test command states mode 0... [full command: udevadm test $(udevadm info -q path -n /dev/input/js0) 2>&1 ]
A part of udev what possibly change the permissions?
KERNEL=="event[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_event}="YES"
KERNEL=="event[0-9]*", ENV{.bogus_mouse_event}="YES", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", MODE="0000"
KERNEL=="js[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="A4TECH USB Device", ENV{.bogus_mouse_js}="YES"
KERNEL=="js[0-9]*", ENV{.bogus_mouse_js}="YES", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", MODE="0000"
No bogus1 and bogus2 are both the same (non-existing) joystick, but one from the Joystick API and one from the evdev interface. In fact one is usually called js0 and the other event13; see also our wiki.
About your points I agree, but I cannot find a way to set mode to 000 or to disable the creation of the bogus nodes... MODE="0000" has apparently no effect.
Edit: probably this note about how to make rule based on two parents can help: http://linhes.org/issues/651#note-6
]]>Did you try with the MODE="0000" instead of your script in the last working rule?
And is not one of 'bogus1' and 'bogus2' a link to the other?
You spoke of 'OPTIONS+=ignore_device' in one of your post;
I don't see that in 'man udev';
do you have a link to some documentation about that option please?
It would be better to prevent the creation of 'bogus1' and 'bogus2', I think;
using 'rm -f' in a script run by root, without any human control, seems dangerous to me.
#!/bin/sh
set -e
cd "/sys/$1"
DUMMYNODES="`ls -1 | grep '^js[0-9]*$\|^event[0-9]*$'`"
cd '/dev/input'
rm -f $DUMMYNODES
I uses the device address to get the names of the bogus nodes and deletes them. Brutal, but effective.
]]>I know the bogus joystick is usually called /dev/input/js0 and /dev/input/event13, but if I plug USB devices in another other is well possible that the name will be different.
The original rule I wrote does not work because in udev rules you can refer to the device (with lines like ATTR or KERNEL) and a single parent (with lines like ATTRS or KERNELS). In that rule instead I refer to multiple parents. So it does not match.
write_down.sh is just a bash script that writes in a file its arguments ("$@"), it was a test to see if udev actually applies the rule when I plugin the mouse. And yes, it works. %k and %n are the kernel name of the device and the kernel number.
Finally, udef devices are organized as tree structure. In this case all the /dev nodes are leaves. But the two bogus ones have a different parent than the good ones.
See this picture:
|
B
-------------------------
| |
X O
---------- -----------
| | | |
bogus1 bogus2 good1 good2
bogus are the two not working /dev devices I want to disable (a non-existing joystick). goods are instead the good ones that represent the mouse.
The rule in previous message correctly detect the X that is parent of the two bogus devices. So my question was, can I avoid the creation of two bogus nodes when I match their parent?
I am also lost.
]]>And in your post #6, what is this: "/root/write_down.sh -- %k -- %n"?
Does this last udev rule works?
And what is the meaning of "Is there a way to stop the device tree from being expanded"? what device tree? expanded by what?
Sorry I am lost...
]]>So I tried something different, this rule gets the parent of the two dummy devices and it should be fairly safe::
ATTR{name}=="A4TECH USB Device", SUBSYSTEM=="input", ATTRS{bInterfaceProtocol}=="01", ATTRS{bInterfaceNumber}=="00", RUN+="/root/write_down.sh -- %k -- %n"
Is there a way to stop the device tree from being expanded? I tried OPTIONS+=ignore_device, but it has no effects.
]]>