USB keyboard media keys only work when connected directly to dom0, not when used through USB qube

[ilyvion]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

---

Expected behavior:

USB keyboard media keys (volume up/volume down, etc.) should work, even when input is protected through sys-usb qube.

Actual behavior:

USB keyboard media keys only work when connected directly to dom0.

Steps to reproduce the behavior:

Install Qubes while a USB keyboard with media keys is connected, so a USB qube isn't created. Verify that media keys work. Enable USB qube by following these instructions. Notice that media keys' functionality ceases.

General notes:

I feel like this should be possible to achieve; my USB mouse's extra buttons (go-back/go-forward) work despite being used through the USB qube, so it's not like special functionality is necessarily prevented by its use.

---

Related issues:

[marmarek]

There is a whitelist of allowed event for each device type:
https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/master/src/input-proxy-receiver.c#L380-L386

In theory all keys are allowed for "keyboard" device type. And indeed I've just checked and it works for me (at least for volume up/down).

There is a helpful debugging tool: evtest
Can you install it and try to look what events your keyboard produce (in both configurations: directly to dom0 and through USB qube)?

[ilyvion]

All right, I installed and ran evtest in both configurations, the outputs are attached below:

dom0-evtest1.txt
dom0-evtest2.txt
usb-evtest1.txt
usb-evtest2.txt

What's clear to me is that most of my special keys (the evtest2 files) disappear when the keyboard goes through the USB qube. And it's even quite accurate, the only feature that still works through the USB qube is the keyboard's "mouse wheel" (EV_REL / REL_WHEEL).

This is my keyboard, should it matter; the remaining functional "mousewheel" is left of the TAB key:

[marmarek]

Ah, I see. Your keyboard expose two devices - one for a standard keyboard and another one for all the multimedia keys. And since the other one lack of "normal keyboard keys" (letters etc), it isn't identified as a keyboard and is connected as a mouse... So, only things that are allowed for mouse works - mouse wheel in this case.

Here is how you can "fix" it manually, after connecting the keyboard:

sys-usb# systemctl |grep qubes-input-sender-mouse
(note `eventX` name in the service name, and use it in two commands below)
sys-usb# systemctl stop qubes-input-sender-mouse@eventX
sys-usb# systemctl start qubes-input-sender-keyboard@eventX

But I have no idea (yet) how to fix autodetection here. You can gather some more information about the device using udevadm info -q all -n input/eventX. Currently udev rules use ID_INPUT_KEYBOARD=1 to identify keyboard.

[ilyvion]

Yup, your "fix" indeed made my media keys work again. Here's the udevadm info for the "media keys" device:

[user@sys-usb ~]$ udevadm info -q all -n input/event3
P: /devices/pci-0/pci0000:00/0000:00:01.0/usb3/3-1/3-1.2/3-1.2:1.1/0003:046D:C30A.0006/input/input3/event3
N: input/event3
S: input/by-id/usb-Logitech_Logitech_USB_Keyboard-if01-event-mouse
S: input/by-path/xen-pci-0-pci-0000:00:01.0-usb-0:1.2:1.1-event-mouse
E: DEVLINKS=/dev/input/by-path/xen-pci-0-pci-0000:00:01.0-usb-0:1.2:1.1-event-mouse /dev/input/by-id/usb-Logitech_Logitech_USB_Keyboard-if01-event-mouse
E: DEVNAME=/dev/input/event3
E: DEVPATH=/devices/pci-0/pci0000:00/0000:00:01.0/usb3/3-1/3-1.2/3-1.2:1.1/0003:046D:C30A.0006/input/input3/event3
E: ID_BUS=usb
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_MOUSE=1
E: ID_MODEL=Logitech_USB_Keyboard
E: ID_MODEL_ENC=Logitech\x20USB\x20Keyboard
E: ID_MODEL_ID=c30a
E: ID_PATH=xen-pci-0-pci-0000:00:01.0-usb-0:1.2:1.1
E: ID_PATH_TAG=xen-pci-0-pci-0000_00_01_0-usb-0_1_2_1_1
E: ID_REVISION=1500
E: ID_SERIAL=Logitech_Logitech_USB_Keyboard
E: ID_TYPE=hid
E: ID_USB_DRIVER=usbhid
E: ID_USB_INTERFACES=:030101:030000:
E: ID_USB_INTERFACE_NUM=01
E: ID_VENDOR=Logitech
E: ID_VENDOR_ENC=Logitech
E: ID_VENDOR_ID=046d
E: LIBINPUT_DEVICE_GROUP=3/46d/c30a/110:usb-0000:00:01.0-1
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: USEC_INITIALIZED=3576051

Here's what I noticed: My USB mouse only has ID_INPUT_MOUSE=1, my USB keyboard has ID_INPUT_KEY=1 and ID_INPUT_KEYBOARD=1, and my USB "media keyboard" has ID_INPUT_KEY=1 and ID_INPUT_MOUSE=1.

If you look in the /lib/udev/rules.d/70-touchpad-quirks.rules file, there are some rules that are specific down to a single device model. So I don't suppose it would be entirely unreasonable to make a rule that looks for the correct combination of ID_MODEL, ID_INPUT_KEY and ID_INPUT_MOUSE and forces it to be recognized as a keyboard?

Unfortunately I'm not familiar enough with udev to really think of how to go about doing this myself.

[marmarek]

Maybe the right thing to do is use ID_INPUT_KEY=1 instead of ID_INPUT_KEYBOARD=1 to detect "keyboard"? Try changing it in /lib/udev/rules.d/90-qubes-input-proxy.rules in all 3 places (directly in USB VM, so you can easily revert by just restarting it). You need to reload udev after: sudo udevadm control -R

[ilyvion]

It didn't do anything right away, but by unplugging and plugging the keyboard back in afterwards, that change made an effect and the media keys now work as expected.

The "media key device" was detected as a keyboard-mouse device. Which makes sense, to be fair, since it's a keyboard which also has a mouse wheel:

[user@sys-usb ~]$ systemctl | grep qubes-input
qubes-input-sender-keyboard-mouse@event3.service  loaded active     running   Qubes input proxy sender (keyboard, fallback to mouse)
qubes-input-sender-keyboard@event2.service        loaded active     running   Qubes input proxy sender (keyboard)
qubes-input-sender-mouse@event1.service           loaded active     running   Qubes input proxy sender (mouse)

[v6ak]

Marek, I can confirm that using ID_INPUT_KEY=1 instead of ID_INPUT_KEYBOARD=1 has fixed the issue for me. I have a different keyboard (Ergodox with TMK firmware) that was identified as two keyboards and two mice. After the fix, it identifies itself as three keyboards (WTF-lol) and one mouse (that's OK), but it works.

I hope it does not break anything else...

[marmarek]

Ok, lets see how it will work on a larger scale. I'll upload a package to testing repo soon.

[v6ak]

Well, it now tries to connect my internal webcam as a keyboard. While it is better, it is not optimal...