Created attachment 280487 [details] dmesg Linux 4.13.0 Hello! Previous bugreport: https://gitlab.freedesktop.org/libinput/libinput/issues/216 gpio-keys drivers keep KEY_LEFTMETA pressed after wakeup from suspend on HP Stream 7 Tablet (Atom Z3735G-based). Linux 4.13.0 is first stable release where I can reliably reproduce this, but only because it's first stable release that able to resume from suspend on this device. gpio-keys started to work before, in 4.11 or 4.12, but I can't verify if this issue is reproducible there, because I can't resume from suspend on this releases.
Hi, I believe that the HP Stream 7 does not actually have a physical "home" / "Windows" button, it only has the capacitive button on the touchscreen, correct? In that case the ACPI table is pointing us to a random GPIO for gpio-keys to actually register the "Windows" / LEFT_META button. I do not know why this GPIO is seen as being pressed after a suspend/resume. But we can fix this by simply binding that button to KEY_NONE. To do this, edit: /lib/udev/hwdb/60-keyboard.hwdb And at the end add: evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* KEYBOARD_KEY_1=unknown And then run: sudo udevadm hwdb --update And reboot, please use a recent kernel as older kernels do not support key rebinding for gpio-keys. If you can confirm that this fixes this, then I will submit a patch upstream to permanently add these lines to 60-keyboard.hwdb
Note the: evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* Is a single line containing "Hewlett-Packard" for some reason bugzilla has decided to split it into 2 lines.
Thank you for looking into this issue! > I believe that the HP Stream 7 does not actually have a physical "home" / > "Windows" button, it only has the capacitive button on the touchscreen, > correct? Yes, this button is part of Goodix touchscreen. > Note the: > evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* > Is a single line containing "Hewlett-Packard" Thanks for this note, I double checked this line, and I didn't forgot to add newline after "KEYBOARD_KEY_1=unknown". Just in case, edited file is here: https://paste.fedoraproject.org/paste/ePVKNvc0svfSBkXQlNHXGg > If you can confirm that this fixes this I tested this workaround with Linux 4.20 and unfortunately it doesn't help.
Hi, What is the output of "cat /sys/class/dmi/id/modalias" on your Stream 7? And can you also run evemu-record on the gpio-keys device causing the homekey to be pressed and copy and paste the output of evemu-record here please? Regards, Hans
Also did you run "sudo udevadm hwdb --update" after updating the file and the reboot? Also please check you don't have a /etc/udev/hwdb/60-keyboard.hwdb file, if you have that file it will override the one in /lib.
> Also did you run "sudo udevadm hwdb --update" after updating the file and the > reboot? Yes, quote from .bash_history: sudo mcedit /lib/udev/hwdb.d/60-keyboard.hwdb sudo udevadm control --reload-rules sudo udevadm hwdb --update I also tried to reboot after this. > Also please check you don't have a /etc/udev/hwdb/60-keyboard.hwdb file, if > you have that file it will override the one in /lib. :~$ ls /etc/udev/hwdb.d | wc -l 0 > What is the output of "cat /sys/class/dmi/id/modalias" on your Stream 7? dmi:bvnInsyde:bvrF.0F:bd09/28/2015:svnHewlett-Packard:pnHPStream7Tablet:pvr0964100000405F100A0360107:rvnHewlett-Packard:rn8031:rvrN/A:cvnHewlett-Packard:ct11:cvrChassisVersion: > And can you also run evemu-record on the gpio-keys device causing the homekey > to be pressed and copy and paste the output of evemu-record here please? ~$ sudo evemu-record Available devices: /dev/input/event0: Video Bus /dev/input/event1: Goodix Capacitive TouchScreen /dev/input/event2: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 /dev/input/event3: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 /dev/input/event4: axp20x-pek /dev/input/event5: HP WMI hotkeys /dev/input/event6: gpio-keys /dev/input/event7: gpio-keys /dev/input/event8: bytcr-rt5640 Headset Select the device event number [0-8]: 7 # EVEMU 1.3 # Kernel: 4.20.5-042005-generic # DMI: dmi:bvnInsyde:bvrF.0F:bd09/28/2015:svnHewlett-Packard:pnHPStream7Tablet:pvr0964100000405F100A0360107:rvnHewlett-Packard:rn8031:rvrN/A:cvnHewlett-Packard:ct11:cvrChassisVersion: # Input device name: "gpio-keys" # Input device ID: bus 0x19 vendor 0x01 product 0x01 version 0x100 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 125 (KEY_LEFTMETA) # Event type 5 (EV_SW) # Event code 12 (SW_ROTATE_LOCK) # State 0 # Properties: N: gpio-keys I: 0019 0001 0001 0100 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 20 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 00 00 00 00 00 00 00 00 B: 05 00 10 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ E: 0.000001 0001 007d 0000 # EV_KEY / KEY_LEFTMETA 0 E: 0.000006 0000 0000 0001 # ------------ SYN_REPORT (1) ---------- +0ms E: 0.470057 0001 007d 0001 # EV_KEY / KEY_LEFTMETA 1 E: 0.470057 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +470ms
(In reply to RussianNeuroMancer from comment #6) > # Event type 5 (EV_SW) > # Event code 12 (SW_ROTATE_LOCK) Ah that explains it, that means the match line needs to be: evdev:name:gpio-keys:phys:gpio-keys/input0:ev:23:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* So the same as before with the "ev:3:dmi" part changed to "ev:23:dmi". Also since the power button is not recognized and the power-button is normally KEYBOARD_KEY_0, we need to map KEYBOARD_KEY_0 now not 1. Note that in future kernels, this patch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=e9eb788f9442d1b5d93efdb30c3be071ce8a22b1 Will change things so that 3 will work. We can use 2 match lines to work with both the old and new kernels. Taking this all together, please try putting this in 60-keyboard.hwdb: evdev:name:gpio-keys:phys:gpio-keys/input0:ev:3:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* evdev:name:gpio-keys:phys:gpio-keys/input0:ev:23:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* KEYBOARD_KEY_0=unknown Note the 2 long lines are single lines, just like last time.
> Taking this all together, please try putting this in 60-keyboard.hwdb Tried it, result the the same. Also tried to remove first line with "ev:3:dmi", but this doesn't help too. > Also since the power button is not recognized You mean "power button is not recognized by gpio-keys"? (On Stream 7 power button detected as part by axp20x-pek.)
fwiw, I usually add FOO=1 as an extra property for my matches and increase it with every change. If udevadm shows the FOO property with the correct value on my device I can be sure that the most recent change was applied. just as a debugging tip.
(In reply to RussianNeuroMancer from comment #8) > > Taking this all together, please try putting this in 60-keyboard.hwdb > > Tried it, result the the same. Also tried to remove first line with > "ev:3:dmi", but this doesn't help too. Please check with evemu-record that the second gpio-keys device is still event7. And then do the following: cat /sys/class/input/input7/phys cat /sys/class/input/input7/capabilities/ev The output should be: gpio-keys/input0 23 If either is different, you need to change the :gpio-keys/input0: or :23: bit in the match line: evdev:name:gpio-keys:phys:gpio-keys/input0:ev:23:dmi:*:svnHewlett-Packard:pnHPStream7Tablet:* To match what you are actually getting. Also make sure that your /lib/udev/rules.d/60-evdev.rules file has lines 15-17 from here: https://github.com/systemd/systemd/blob/master/rules/60-evdev.rules#L15 If not the file is too old, please replace it with the one from the systemd github repo. Also please check you do not have an /etc/udev/rules.d/60-evdev.rules file. > > Also since the power button is not recognized > > You mean "power button is not recognized by gpio-keys"? (On Stream 7 power > button detected as part by axp20x-pek.) Right, that is what I meant.
> fwiw, I usually add FOO=1 as an extra property for my matches and increase it > with every change. If udevadm shows the FOO property with the correct value > on my device I can be sure that the most recent change was applied. just as a > debugging tip. Yes, both of KEYBOARD_KEY_1=unknown and FOO=1 is present in udevadm output: ~$ udevadm info --query=property --name=/dev/input/event7 BACKSPACE=guess DEVLINKS=/dev/input/by-path/platform-gpio-keys.2.auto-event DEVNAME=/dev/input/event7 DEVPATH=/devices/platform/gpio-keys.2.auto/input/input7/event7 FOO=1 ID_INPUT=1 ID_INPUT_KEY=1 ID_INPUT_SWITCH=1 ID_PATH=platform-gpio-keys.2.auto ID_PATH_TAG=platform-gpio-keys_2_auto KEYBOARD_KEY_1=unknown LIBINPUT_DEVICE_GROUP=19/1/1:gpio-keys MAJOR=13 MINOR=71 SUBSYSTEM=input TAGS=:power-switch: USEC_INITIALIZED=14933748 XKBLAYOUT=us,ru XKBMODEL=pc105 XKBOPTIONS=grp:alt_shift_toggle,grp_led:scroll XKBVARIANT=, However I still can't get why reboot is required to commit changes. This time I tried running "sudo udevadm hwdb --update" first and "sudo udevadm control --reload-rules" second, and the other way around, yet FOO=1 doesn't appear in udevadm output until I perform reboot. > Please check with evemu-record that the second gpio-keys device is still > event7. Yes, it's still event7. > The output should be: Correct: ~$ cat /sys/class/input/input7/phys gpio-keys/input0 ~$ cat /sys/class/input/input7/capabilities/ev 23 > Also make sure that your /lib/udev/rules.d/60-evdev.rules file has lines > 15-17 from here: > https://github.com/systemd/systemd/blob/master/rules/60-evdev.rules#L15 Yes, this lines is present. ~$ cat /lib/udev/rules.d/60-evdev.rules | grep "capabilities" KERNELS=="input*", IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:phys:$attr{phys}:ev:$attr{capabilities/ev}:$attr{[dmi/id]modalias}'", \ > Also please check you do not have an /etc/udev/rules.d/60-evdev.rules file. This folder is empty: ~$ ls /etc/udev/rules.d | wc -l 0
(In reply to RussianNeuroMancer from comment #11) > > fwiw, I usually add FOO=1 as an extra property for my matches and increase > it > > with every change. If udevadm shows the FOO property with the correct value > > on my device I can be sure that the most recent change was applied. just as > a > > debugging tip. > > Yes, both of KEYBOARD_KEY_1=unknown and FOO=1 is present in udevadm output: Ok, so FOO=1 being there is good, this means the match part of the hwdb entry works, but it looks like you missed my remark about the key-mapping needing to be: "KEYBOARD_KEY_0=unknown" because the power-button is not handled by gpio-keys. If you replace "KEYBOARD_KEY_1=unknown" with "KEYBOARD_KEY_0=unknown" then I believe things should work. > However I still can't get why reboot is required to commit changes. This > time I tried running "sudo udevadm hwdb --update" first and "sudo udevadm > control --reload-rules" second, and the other way around, yet FOO=1 doesn't > appear in udevadm output until I perform reboot. You can get the FOO=1 to show up with a "udevadm trigger" command, which emulates re-plugging all devices, so that the hwdb entry gets re-evaluated.
> it looks like you missed my remark about the key-mapping needing to be: > "KEYBOARD_KEY_0=unknown" because the power-button is not handled by gpio-keys Sorry, I indeed missed this. > If you replace "KEYBOARD_KEY_1=unknown" with "KEYBOARD_KEY_0=unknown" then I > believe things should work. Yes, KEY_LEFTMETA is not pressed by gpio-keys now: Event: time 1549109508.128691, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1 Event: time 1549109508.128691, -------------- SYN_REPORT ------------ Event: time 1549109565.344864, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0 Event: time 1549109565.344869, -------------- SYN_REPORT ------------ Event: time 1549109571.127380, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1 Event: time 1549109571.127380, -------------- SYN_REPORT ------------ Event: time 1549109578.852365, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 0 Event: time 1549109578.852371, -------------- SYN_REPORT ------------ Event: time 1549110851.127087, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1 Event: time 1549110851.127087, -------------- SYN_REPORT ------------ > You can get the FOO=1 to show up with a "udevadm trigger" command, which > emulates re-plugging all devices, so that the hwdb entry gets re-evaluated. Thanks, that help to apply fix without reboot. Should I close this or keep it open as original issue with gpio-keys?
Great. Thank you for testing the solution for this. I've submitted a pull-req adding a hwdb entry for this upstream here: https://github.com/systemd/systemd/pull/11631 I do not believe that we are ever going to fix the issue with the GPIO for the non existing button reading 1 after suspenf/resume, so lets close this bug.
fwiw: udevadm hwdb --update" ... compiles the .hwdb file in to the /etc/udev/hwdb.bin file which is used for lookups udevadm control --reload-rules ... notification that .rules files have changed udevadm test ... test-but-dont-apply rules for a specific device, so you can check if something works without changing the device (note: it does apply things when you run it as root, because reasons) udevadm trigger ... apply the udev rules to a specific device for a specific event. This emulates unplugging/replugging the device.
Thanks! Which one I should execute first, "udevadm hwdb --update" or "udevadm control --reload-rules" to be able to udevadm trigger?
doesn't matter, the hwdb rebuild is independent of the rules so as long as you run both before trigger, it'll work.