-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The "-rm" version breaks systems by deleting device nodes that are still referenced by the udev database #58
Comments
@foresto I'm the packager who added the udev rule in the Your approach in Suggestion 1 seems to be the best, I'll make a Pull Request proposal for that. I don't have one device that falls into this list since a very long time (at least ~8 years) so I won't be able to test, but I will ask the user to test. |
That's even better. I think we should add all the IDs in this project in the very same way and get rid of the custom udev rule. This repository is very old and the drivers have never been fixed, so putting it there sounds like the best approach. We can generate the modalias skipping the version id and just using Vendor and Product I guess. |
Do we need anything else beside Example:
|
If I'm reading correctly, except the ASRock LED Controller all the others are anyway input devices (mouse, keyboard, tablet). |
While I have no doubt that these rules were written with good intentions,
51-these-are-not-joysticks-rm.rules
is putting systems in a bad state by deleting device nodes that are still referred to by udev.The consequence: any software that correctly discovers joysticks by querying udev or reacting to udev events will fail when it tries to open their device nodes, because the node (e.g. /dev/input/js0) doesn't actually exist.
Unfortunately, this rules file has made its way into some widely used packages, such as certain redistributions of Valve's "steam-devices" udev rules collection, thereby causing mysterious failures that shouldn't occur.
Please consider using a different approach.
Suggestion 1:
ACTION=="bind", SUBSYSTEM=="hid", ATTR{driver/unbind}="%k"
Suggestion 2:
SUBSYSTEM=="usb", ATTR{authorized}="0"
I spent more than a few hours tracing a failure caused by these rules to its source. It was tough to pin down, because most users who have affected devices don't know enough about how these things work to diagnose them on their own, and most people who have the knowledge don't have the affected devices and don't expect custom udev rules to be deleting device nodes.
Thanks for your attention.
The text was updated successfully, but these errors were encountered: