Bug 202279

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.