Yes, there is a legitimate reason for removing devices, and a special way to do it. In my case, I needed to because my cheap USB numpad exported two evdev-compatible devices with the same name. This confused evdev-plug… especially since one of them is completely inert.
The trick is to find the modalias for the troublesome interface in question. That will uniquely identify that evdev interface file leaving the other one untouched. Assuming the device node is /dev/input/event6, this should do the trick:
udevinfo -a -p `udevinfo -q path -n /dev/input/event6` | grep 'ATTRS{modalias}=="usb'
Take the output of that line and substitute it into this udev rule: (See my previous post for details))
BUS=="usb", ATTRS{modalias}=="usb:v1267p0103d0101dc00dsc00dp00ic03isc00ip00", OPTIONS="ignore_device"
It should be pretty self-explanatory.
UPDATE: On a related note, if you are using one of those Mouse+Keyboard USB-to-PS/2 bridges and don’t mind the lack of “Plug and Play”-like flexibility, the simplest way to select one of the two devices is to use something like this:
Driver "evdev" Option "Name" "CHESEN PS2 to USB Converter" Option "Phys" "*/input0"
You can get the values for Name and Phys using
cat /proc/bus/input/devices
udev and evdev: Removing devices by Stephan Sokolow is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
I’m having problems with my cheap USB numpad. However, I don’t know how to diagnose that it’s “exporting two evdev-compatible devices with the same name.” Can you provide
udevadmoutput or device listings that proves this?My exact problem is at http://unix.stackexchange.com/questions/56301/netbook-w-fedora-17-and-usb-numpad-at-boot-disables-internal-keyboard.
My cheap USB numpad doesn’t have a udev
ATTRS{modalias}line.Here’s a paste from /var/log/messages:
Does
input6andinput0mean that I have the symptoms described above?Thanks, Stephan!
Hmm. I looked at your StackExchange question and, while this might possibly fix the problem, it wouldn’t fix the real issue, which means it might break again down the line.
I just discovered that their compatibility with Verisign/Symantec PIP OpenIDs is broken, so I can’t log in to respond there right now, but I’ll do what I can here and you’ll just have to check for updates manually.
Anyway, I don’t have much experience with the kernel input subsystem beyond basic device handling and I have no experience with Fedora (I don’t like RPM or PulseAudio and I don’t like the direction systemd adoption seems to be going), but here are my suggestions for trying to get more details on the problem (assuming that Fedora’s udev config isn’t TOO different from that of Gentoo and Debian-based distros):
1. Check whether the
inputXnumbers in your paste correspond to/dev/input/eventXdevice nodes.2. Check whether the names in your paste show up in
/dev/input/by-id/3. Check whether the complex identifier numbers in your paste show up in
/dev/input/by-path/4. Try using
catto see whether any input gets generated on said nodes when you press keys on your numpad.5. (optional) Use
rc.localor equivalent to log those device nodes before you press numlock to see how things differ.6. Try using udev to remove each node you find one-by-one to see if it fixes it.
You can filter on any udev attribute, not just
ATTRS{modalias}. I just used that because, for me, it was the easiest way to uniquely-identify that device node without also catching the other one my numpad provides.Pingback: Unix:Netbook w/ Fedora 17 and USB Numpad at Boot Disables Internal Keyboard – Unix Questions