Bug 202279 - gpio-keys keep KEY_LEFTMETA pressed after wakeup from suspend on HP Stream 7 Tablet
Summary: gpio-keys keep KEY_LEFTMETA pressed after wakeup from suspend on HP Stream 7 ...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Platform_x86 (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: drivers_platform_x86@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-15 11:39 UTC by RussianNeuroMancer
Modified: 2019-02-04 07:56 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.13.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg Linux 4.13.0 (51.73 KB, text/plain)
2019-01-15 11:39 UTC, RussianNeuroMancer
Details

Description RussianNeuroMancer 2019-01-15 11:39:08 UTC
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.
Comment 1 Hans de Goede 2019-01-26 14:44:59 UTC
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
Comment 2 Hans de Goede 2019-01-26 14:46:06 UTC
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.
Comment 3 RussianNeuroMancer 2019-01-28 14:32:57 UTC
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.
Comment 4 Hans de Goede 2019-01-28 14:53:11 UTC
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
Comment 5 Hans de Goede 2019-01-28 14:56:15 UTC
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.
Comment 6 RussianNeuroMancer 2019-01-29 15:32:54 UTC
> 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
Comment 7 Hans de Goede 2019-01-29 16:09:25 UTC
(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.
Comment 8 RussianNeuroMancer 2019-01-30 01:00:46 UTC
> 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.)
Comment 9 Peter Hutterer 2019-01-30 05:10:11 UTC
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.
Comment 10 Hans de Goede 2019-01-31 12:25:04 UTC
(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.
Comment 11 RussianNeuroMancer 2019-02-02 08:56:31 UTC
> 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
Comment 12 Hans de Goede 2019-02-02 10:41:04 UTC
(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.
Comment 13 RussianNeuroMancer 2019-02-02 13:05:58 UTC
> 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?
Comment 14 Hans de Goede 2019-02-02 13:47:57 UTC
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.
Comment 15 Peter Hutterer 2019-02-03 23:02:16 UTC
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.
Comment 16 RussianNeuroMancer 2019-02-04 07:28:37 UTC
Thanks! Which one I should execute first, "udevadm hwdb --update" or "udevadm control --reload-rules" to be able to udevadm trigger?
Comment 17 Peter Hutterer 2019-02-04 07:56:56 UTC
doesn't matter, the hwdb rebuild is independent of the rules so as long as you run both before trigger, it'll work.

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