My suggestion is that you install the application input-utils
sudo -i
apt-get update
apt-get install input-utils
This is a collection of utilities which are useful when working with
the input layer of the Linux kernel (version 2.6 and later). Included
are utilities to list the input devices known to the kernel, show
the input events that are received by a device, and query or modify
keyboard maps.
The command of interest is:
sudo -i
lsinput
It dumps out all the input devices and the associated details about the device.
One can observe input events using the command, by specifing the Nth device number:
sudo -i
input-events <device number>
One can then dump out the keyboard mapping of a particular event device using the command ,by specifing the Nth device number:
sudo -i
input-kyb <device number>
With these tools one can debug a system to see if inputs generate the expected event codes and hence help sort out issues such as why keys don't work or are mapped incorrectly.
Udev is the device manager for the Linux kernel. It manages device nodes in /dev and handles all user space actions when adding or removing devices.
Evdev is a generic input event interface in the Linux kernel.It generalizes raw input events from device drivers and makes them available through character devices in the /dev/input/
directory.
Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as declared in the /etc/udev/rules.d, /run/udev/rules.d and /lib/udev/rules.d directories.
Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions.
These actions can be creating or deleting device files, but can also trigger the loading of particular firmware files into kernel memory.
/dev/input/event/*
then you're essentially giving everyone access to sniff your keyboard, for example passwords that you type. On a single-user system this might not matter so much, but even on a single-user system we generally use system users as an extra layer of safety in case some component gets compromised, and by giving for example thenobody
user access to your keyboard input stream you are weakening this protection. While this might "fix" Mumble, it isn't an appropriate general solution to your problem. There should be a better way./dev/input
are wrong, and what the ownership and permissions currently are (perhaps with the output ofls -l
)? Is the problem that theinput
group doesn't have read permissions (or that it is not the group owner)? On my system the event files haveroot:input
ownership and both the user and group owners can read from them. If you don't have this, you should perhaps try to set it up that way rather than letting everyone read them. If you do have this, it may be enough for Mumble to run with the powers of theinput
group.