Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUSB keyboard media keys only work when connected directly to dom0, not when used through USB qube #2781
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Apr 27, 2017
Member
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)?
|
There is a whitelist of allowed event for each device type: 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: |
andrewdavidwong
added
the
C: other
label
Apr 27, 2017
andrewdavidwong
added this to the Release 3.2 updates milestone
Apr 27, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alexschrod
Apr 28, 2017
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:
alexschrod
commented
Apr 28, 2017
|
All right, I installed and ran evtest in both configurations, the outputs are attached below: dom0-evtest1.txt What's clear to me is that most of my special keys (the This is my keyboard, should it matter; the remaining functional "mousewheel" is left of the TAB key: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Apr 28, 2017
Member
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.
|
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: But I have no idea (yet) how to fix autodetection here. You can gather some more information about the device using |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alexschrod
Apr 28, 2017
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.
alexschrod
commented
Apr 28, 2017
|
Yup, your "fix" indeed made my media keys work again. Here's the Here's what I noticed: My USB mouse only has If you look in the Unfortunately I'm not familiar enough with udev to really think of how to go about doing this myself. |
andrewdavidwong
added
the
bug
label
Apr 29, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 8, 2017
Member
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
|
Maybe the right thing to do is use |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
alexschrod
May 10, 2017
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)
alexschrod
commented
May 10, 2017
•
edited
Edited 1 time
-
alexschrod
edited May 10, 2017 (most recent)
edited
-
May 10, 2017 (most recent)
|
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: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
v6ak
May 14, 2017
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...
v6ak
commented
May 14, 2017
|
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... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 14, 2017
Member
Ok, lets see how it will work on a larger scale. I'll upload a package to testing repo soon.
|
Ok, lets see how it will work on a larger scale. I'll upload a package to testing repo soon. |
marmarek
closed this
in
marmarek/qubes-app-linux-input-proxy@20ebd32
May 14, 2017
This was referenced May 14, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
v6ak
May 15, 2017
Well, it now tries to connect my internal webcam as a keyboard. While it is better, it is not optimal...
v6ak
commented
May 15, 2017
|
Well, it now tries to connect my internal webcam as a keyboard. While it is better, it is not optimal... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 15, 2017
Member
|
On Mon, May 15, 2017 at 01:07:32PM -0700, Vít Šesták wrote:
Well, it now tries to connect my internal webcam as a keyboard. While it is better, it is not optimal...
Well, your internal webcam probably do expose some key events. Mine do:
```
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 212 (KEY_CAMERA)
Properties:
```
This is very interesting, I have no idea where this button physically
is. But I've seen a button on some external USB cameras, so maybe it's
simply the same hardware in a different chassis...
Maybe @Rudd-O idea in #2783 is the way to go?
…--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rudd-O
commented
May 15, 2017
|
Yay!
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
v6ak
May 16, 2017
v6ak
commented
May 16, 2017
|
Well, your internal webcam probably do expose some key events. Mine do:
Mine looks similar.
Well, if it really exposes keys, it can be considered as a feature (though annoying) rather than as a bug.
This is very interesting, I have no idea where this button physically
is. But I've seen a button on some external USB cameras, so maybe it's
simply the same hardware in a different chassis...
Or different hardware with the same firmware…
That sounds like the right way.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Rudd-O
May 16, 2017
Rudd-O
commented
May 16, 2017
|
It would also be excellent if the usbvm could present a tray icon showing the status of the deny_new_usb toggle in /sys, and allowing one to toggle it on and off. I am on email so I cannot open a ticket, but this would to be phenomenal to add as a new ticket.
…On May 15, 2017 10:20:41 PM GMT+02:00, "Marek Marczykowski-Górecki" ***@***.***> wrote:
On Mon, May 15, 2017 at 01:07:32PM -0700, Vít Šesták wrote:
> Well, it now tries to connect my internal webcam as a keyboard. While
it is better, it is not optimal...
Well, your internal webcam probably do expose some key events. Mine do:
```
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 212 (KEY_CAMERA)
Properties:
```
This is very interesting, I have no idea where this button physically
is. But I've seen a button on some external USB cameras, so maybe it's
simply the same hardware in a different chassis...
Maybe @Rudd-O idea in #2783 is the way to go?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2781 (comment)
--
Rudd-O
http://rudd-o.com/
|
alexschrod commentedApr 27, 2017
•
edited
Edited 1 time
-
alexschrod
edited Apr 27, 2017 (most recent)
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: