Fix for keyboard/mouse/tablet being detected as joystick in Linux.
There are several devices that, although recognized by kernel as joysticks, are not joysticks. This repository contains rules that will prevent the non-functional
/dev/input/event* devices from being recognized as joysticks.
This is just a blacklist, which will always be incomplete (until the actual bug gets fixed). Feel free to add more devices to this list.
sudo curl -o /etc/udev/rules.d/51-these-are-not-joysticks.rules \ https://raw.githubusercontent.com/denilsonsa/udev-joystick-blacklist/master/51-these-are-not-joysticks.rules
sudo curl -o /etc/udev/rules.d/51-these-are-not-joysticks-rm.rules \ https://raw.githubusercontent.com/denilsonsa/udev-joystick-blacklist/master/51-these-are-not-joysticks-rm.rules
Personally, I'd try the first version (that sets permissions to
0000) first. If it does not work or if it gives trouble for some reason, I'd try the second version (that removes the device).
The first version (that sets permissions to
0000) seems to work fine across several distros, but some distros (such as OSMC, see also issue #26) may have additional rules that end up setting the permssions back to another value. In such case, the second version (that removes the device) should work.
In the end, it's up to you, and it's about what works best for you and your system.
A patch has been accepted into Linux kernel 4.9, so that Microsoft devices will not be detected as joysticks anymore. Thus, those devices are not included in
after_kernel_4_9/*. Read issue #20 for details.
A rule will match if:
idProductis in this list;
The following actions are taken on each matching rule:
ID_INPUT_JOYSTICKproperty, which prevents some
/lib/udev/rules.d/*rules from running.
MODE="0000". This effectively prevents the device from being used.
/dev/input/. This also prevents the device from being found or from being listed.
It is not possible to rename a device, so
NAME="not-a-joystick%n" will not work.
Look at the generated
ls -l /dev/input/
Unplug and plug your USB device while monitoring for kernel and udev events:
udevadm monitor -p
Look for other udev rules that may interact with the same device:
grep -i '\bjs\b\|joystick' /lib/udev/rules.d/* /etc/udev/rules.d/*
These tools list and interact with all available/detected joysticks:
/dev/input/event*devices that are marked with
There are reports of this issue on different distros and projects.
The udev rules in this repository have been added to:
joystickpackage, starting on version 1.4.9-1
But remember that the version distributed elsewhere might be different than the version on this repository.
For the complete list, look at
The best ways to contribute are by creating a new issue or by making a pull request. Make sure you mention the device name/description and the vendor/product IDs. The relevant line from
lsusb output is usually enough.
This repository contains a list of devices compiled from contributions of several people. I cannot test every single device. If something does not work for you even after you have added the correct rules, please try debugging it on your own system. The output of
udevadm monitor -p may prove very helpful. Also look at the output of
ls -l /dev/input/.
After suffering with this issue for a long time, I decided to investigate possible fixes and workarounds. Then, in May 2015, after searching a lot for a solution, I've managed to create some udev rules that fixed the issue for my devices and decided to share this solution with other people. Initially, I shared the simple file at GitHub Gist. Over time, people submitted contributions through comments, and keeping that file on Gist was becoming too hard to manage.
In October 2015, I decided to move the file to this GitHub repository. That way, it will be easier to make changes, to fork, to receive notifications, and essentially to maintain it.
Ideally, the bug in the Linux kernel should be fixed, so that this repository (which is essentially just a workaround) wouldn't be needed anymore.
Public domain. Feel free to use this project for whatever purpose you want.
Also, feel free to contribute to the project. And, if you have the knowledge and the skills, consider fixing this bug in the Linux kernel itself.
There is no warranty implied by using this project. Use at your own risk.