Bug 1662530 - Multimedia keys mapped to KEY_UNKNOWN
Summary: Multimedia keys mapped to KEY_UNKNOWN
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 28
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-29 12:39 UTC by stefan.ku
Modified: 2019-01-22 18:30 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-01-21 23:36:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description stefan.ku 2018-12-29 12:39:30 UTC
Description of problem:

Some of the multimedia keys on the detachable keyboard of the X1 tablet gen3 (vendorid 17ef product id 60b5) do get mapped to KEY_UNKNOWN. Looking at the usbmon log, the data sent to the controller has an additional byte (see log below for an example).  

Is there any way to make these keys useful/mappable?

Output of
evtest and 
cat /sys/kernel/debug/usb/usbmon/1u
when pressing first volume up and then the mute microphone button

Event: time 1546085932.425423, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00e9
Event: time 1546085932.425423, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1546085932.425423, -------------- SYN_REPORT ------------
Event: time 1546085932.512997, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00e9
Event: time 1546085932.512997, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1546085932.512997, -------------- SYN_REPORT ------------
Event: time 1546085933.537414, type 4 (EV_MSC), code 4 (MSC_SCAN), value c0001
Event: time 1546085933.537414, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1
Event: time 1546085933.537414, -------------- SYN_REPORT ------------
Event: time 1546085933.633413, type 4 (EV_MSC), code 4 (MSC_SCAN), value c0001
Event: time 1546085933.633413, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0
Event: time 1546085933.633413, -------------- SYN_REPORT ------------


ffff8f7147b7b000 65566556 C Ii:1:002:2 0:8 3 = 02e900
ffff8f7147b7b000 65566625 S Ii:1:002:2 -115:8 8 <
ffff8f7147b7b000 65686290 C Ii:1:002:2 0:8 3 = 020000
ffff8f7147b7b000 65686320 S Ii:1:002:2 -115:8 8 <
ffff8f7147b7b000 65894572 C Ii:1:002:2 0:8 4 = 03000200
ffff8f7147b7b000 65894659 S Ii:1:002:2 -115:8 8 <
ffff8f7147b7b000 65982526 C Ii:1:002:2 0:8 4 = 03000000
ffff8f7147b7b000 65982603 S Ii:1:002:2 -115:8 8 <

Comment 1 Peter Hutterer 2019-01-21 23:36:29 UTC
libinput doesn't do anything with keys, it just passes them on. What you need here is an entry in systemd's 60-keyboard.hwdb file to tell the kernel what key to map each unknown scancode to. There are already a few lenovo entries, your entry will look something like this:

evdev:input:b0003v17efp60B5*
 KEYBOARD_KEY_c0001=f20                                     # micmute

There are instructions at the top of the 60-keyboard.hwdb file for how to apply and test, please check there for more info. And if there are other keys that don't work simply rinse, wash, repeat.


Closing this bug, once you add this upstream it'll feed back into Fedora anyway.

Comment 2 stefan.ku 2019-01-22 18:30:10 UTC
The problem is that there are multiple keys that throw a scancode of "c0001". So remapping c0001 would result in all those keys being remapped to the the same function, e.g. f20. Also when I tried it was not possible to remap scancode c0001. Could you suggest against what or where to file the bug?


Note You need to log in before you can comment on or make changes to this bug.