Version: 2:1.11.1.902-1 Undeniable proof that xserver-xorg-core cannot read symlinks here: $ cat /usr/share/X11/xorg.conf.d/66-jidanni.conf Section "InputClass" Identifier "Bypassed Busted Keyboard" MatchIsKeyboard "on" MatchDevicePath "/dev/input/by-path/platform-i8042-serio-0-event-kbd" Option "Ignore" "on" EndSection Does not work. If one uses instead MatchDevicePath "/dev/input/event0" then it works perfectly. Even though $ ls -og /dev/input/by-path/platform-i8042-serio-0-event-kbd lrwxrwxrwx 1 9 11-15 07:08 /dev/input/by-path/platform-i8042-serio-0-event-kbd -> ../e Removing MatchIsKeyboard "on" does not help.
We get our device information from udev, including the device path. Any MatchFoo statements are matched against the information we get from udev. The device path is always /device/input/eventX, and we don't really look at the symlinks to the device. It's possible to do so, but it's quite a bit of work (we have to store multiple paths in the InputAttributes and match against them) and I'm not sure the extra complexity really pays off.
Holy moly, this breaks the whole UNIX model. The last time I heard about programs not obeying symlinks must have been 1980. Plus it is only partial... I'm sure you obey them if the whole filesystem was on one ... harder to debug. Well at least document it all over the man pages, and some error message in /var/log/Xorg.0.log . Anyway the whole point of /dev/input/by-* is so users can distinguish between different kinds of devices ... beyond the crude MatchIsKeyboard ...
Doesn't the make the program "No longer UNIX/Linux/Posix/GNU complaint, thus no longer able to wear the certification badge and qualify for grants" or something? Repent now!
the->this
closing as WONTFIX. For reasons why see http://who-t.blogspot.com/2011/11/bugzilla-attention-span.html and your comments 2-4. Feel free to re-open once you bother to try to understand what's actually going on instead of spewing sensationalist misinformed crap.
Ignoring all the crap about 'breaking UNIX/POSIX compliance' (we have no badge to hand back anyway), this would be very, very difficult to implement. As MatchDevicePath lets you specify wildcards, this could potentially mean you have to traverse the entire filesystem to satisfy a MatchDevicePath, as there is no canonical list of symlinks referring back to a single device. So, just on complexity and potential for disaster alone, I don't think this will ever be implemented.
PS: / cannot be a symlink, for reasons I hope are obvious.
While there isn't a list of all symlinks everywhere that point to the device, udev does maintain and provide the list of symlinks it knows about, which would be sufficient for the reporter. udev_device_get_devlinks_list_entry() could be called and the result enumerated within config/udev.c to at least find those Since that includes the /dev/input/by-* symlinks, it would be sufficient for the reporter's needs
(In reply to comment #8) > While there isn't a list of all symlinks everywhere that point to the device, > udev does maintain and provide the list of symlinks it knows about, which would > be sufficient for the reporter. when I looked at it yesterday it looked we could add this but there is some effort involved, most likely affecting InputAttributes and thus the slew of changes that requires. Not impossible, but likely effort that I cannot spend at this point. If you're happy to provide patches, go for it.
Think of it this way, some devices might be very easy to distinguish by their by-id etc. paths, but very hard to distinguish by hoping the order they are added by USB works out the same each time. E.g., two mice, two keyboards, etc. In my case I am just lucky that the target keyboard I want to treat is always added first. Not necessarily the case with two almost identical USB mice.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.