Bug 1662530

Summary:	Multimedia keys mapped to KEY_UNKNOWN
Product:	[Fedora] Fedora	Reporter:	stefan.ku
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	dingyichen, lnykryn, msekleta, peter.hutterer, ssahani, s, systemd-maint, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-21 23:36:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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?