Currently Mumble tries to open /dev/input/eventX device and appends it to inputs/keyboard list on success, silently ignoring any errors (i.e. permission denied). If no "keyboard" can be detected it falls back to XInput.
It's completely fine as long if user has access to all devices under /dev/input or has no access at all (which is probably the default on most distributions for security reasons). On my system however, I use fancy utility to control my mouse and thus I modified my udev rules to gain "raw" access to my mouse (and only it), effectively the only input device seen by Mumble is my mouse..
Now, this setup might be rare, nevertheless as far I can tell there is no mention of possible problems with shortcuts (i.e. "gotchas") in documentation, nor any indication in Mumble logs (putting aside lack of most input devices in messages from GlobalShortcutX).
There are a few possible solutions/improvement proposals:
- warn user about file permissions (in console output), instead of silently ignoring them, so at the very least user can get a clue what's wrong
- warn user if some devices cannot be read (e.g. like my setup), this time with some annoying GUI popup or log message (GUI window)
- update wiki/documentation (mention it in FAQ ?)
- provide option to disable raw input completely and use XInput by defaut
- (probably not the best option, can be tricky to implement) provide XInput fallback for devices which won't allow read access (i.e. hybrid mode)
Log in to post a comment.