I am running Kubuntu 20.04 on the LG Gram 14 2-in-1 (late 2020, 14T90N-R.AAS9U1), and having a problem with the volume up/down keys -- they act as if they are held down even when pressed and released once. This makes them unusable, since pressing the volume up key once produces an uncontrollable sequence of many volume increases in rapid succession, and likewise for the volume down key. This is easy to work around by just not using these keys and adjusting the volume using the KDE GUI interface, but it bothers me (pressing the keys, even if accidentally, can be a frustrating experience) and I'd like to get it fixed if at all possible.
A bit of googling turned up this review on r/linuxhardware, where another LG Gram owner reports the same issue. I also found this question about a similar issue affecting a Medion laptop, which was solved here -- in that case, it seemed that the issue was related to the keyboard sending key press events, but not key release events. For me, evtest
reports the key press events for the up, down, and mute keys as follows:
Event: time 1612631058.064924, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1c
Event: time 1612631058.064924, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1612631058.064924, -------------- SYN_REPORT ------------
Event: time 1612631061.892791, type 4 (EV_MSC), code 4 (MSC_SCAN), value ae
Event: time 1612631061.892791, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 2
Event: time 1612631061.892791, -------------- SYN_REPORT ------------
Event: time 1612631062.251943, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1612631062.251943, -------------- SYN_REPORT ------------
Event: time 1612631063.627541, type 4 (EV_MSC), code 4 (MSC_SCAN), value b0
Event: time 1612631063.627541, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 2
Event: time 1612631063.627541, -------------- SYN_REPORT ------------
Event: time 1612631064.024607, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1612631064.024607, -------------- SYN_REPORT ------------
Event: time 1612631066.166541, type 4 (EV_MSC), code 4 (MSC_SCAN), value a0
Event: time 1612631066.166541, type 1 (EV_KEY), code 113 (KEY_MUTE), value 2
Event: time 1612631066.166541, -------------- SYN_REPORT ------------
Event: time 1612631066.486291, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Since there is only one event reported for each key press (rather than separate key press and release events), I concluded that my issue was the same, and I tried to modify the solution to work in my case. In the comments at the top of /lib/udev/hwdb.d/60-keyboard.hwdb
, I discovered the following:
# Supported hardware matches are:
[...]
# - AT keyboard DMI data matches:
# evdev:atkbd:dmi:bvn*:bvr*:bd*:svn<vendor>:pn<product>:pvr*
# <vendor> and <product> are the firmware-provided strings
# exported by the kernel DMI modalias, see /sys/class/dmi/id/modalias
[...]
# To update this file, create a new file
# /etc/udev/hwdb.d/70-keyboard.hwdb
# and add your rules there. To load the new rules execute (as root):
# systemd-hwdb update
# udevadm trigger /dev/input/eventXX
# where /dev/input/eventXX is the keyboard in question. If in
# doubt, simply reload all input rules
# udevadm trigger --verbose --sysname-match="event*"
For me, /sys/class/dmi/id/modalias
reads
dmi:bvnAmericanMegatrendsInc.:bvr14T90F03:bd02/27/2020:svnLGElectronics:pn14T90N-R.AAS9U1:pvr1.0:rvnLGElectronics:rn14T90N:rvr1.0:cvnLGElectronics:ct31:cvrNotused:
Based on this and the previously mentioned answer, I created a file /lib/udev/hwdb.d/70-volume-keys-fix.hwdb
with the contents
# Fix for volume keys on LG Gram keyboard
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLGElectronics:pnP*:pvr*
KEYBOARD_KEY_a0=!mute
KEYBOARD_KEY_ae=!volumedown
KEYBOARD_KEY_b0=!volumeup
and ran sudo systemd-hwdb update; udevadm trigger --verbose --sysname-match='event*'
to get the changes to take effect. The only effect this had was to disable the volume up/down keys entirely.
What can I do to get the keys to work properly?
pnP*
part wasn't matching. I adjusted/lib/udev/hwdb.d/70-volume-keys-fix.hwdb
, and now it works! I'll look into creating a PR for systemd. – Ross Jennings Sep 05 '21 at 20:38bd*
part. Not sure if this affects it or not, but I kept it in my version. – Ross Jennings Sep 05 '21 at 20:40