Bug 103561 - libinput 1.8.3 -> 1.9.1: laptop keyboard not working
Summary: libinput 1.8.3 -> 1.9.1: laptop keyboard not working
Status: RESOLVED NOTOURBUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
: 103571 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-11-03 14:16 UTC by Kristian Rink
Modified: 2017-11-15 15:31 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
libinput debug-events (1.45 KB, text/plain)
2017-11-03 20:06 UTC, demaio
Details
evemu log (16.08 KB, text/plain)
2017-11-06 16:29 UTC, zeng.shixin
Details
libinput debug: last git commit (4.48 KB, text/plain)
2017-11-08 17:46 UTC, Stefano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Rink 2017-11-03 14:16:06 UTC
Updated libinput from 1.8.3 to 1.9.1 on Arch on an HP EliteBook laptop. Outcome: Internal keyboard doesn't work anymore (in X11). Keyboard works in tty though, and connecting an external (USB) keyboard works too.

Haven't so far filed a bug report here so I'm not aware whether I provide all the info you need - feel free to ask back if you need anything else. :|
Comment 1 bernie 2017-11-03 16:52:28 UTC
Dear Peter Hutterer,

I have upgraded to libinput 1.9.1-1 in ArchLinux 64bit.
But after the restart my PS/2 connected keyboard (Desktop PC, X11) is not working with linux-lts 4.9.59-1 anymore, but with linux 4.13.10-1. 
=> No input is possible via keyboard , no num-lock led activation is possible. 

The keyboard is detected as you can see in the ArchLinux bug report logs.
https://bugs.archlinux.org/task/56207?project=1&order=dateopened&sort=desc

Replug does not help. The mouse via usb works.  
When I use a USB keyboard there is no problem.

Downgrading to libinput 1.8.3-1 helps. 

Faulty version: libinput 1.9.1-1

Last working: libinput 1.8.3-1 with linux-lts and linux kernel 4.13.x

But libinput 1.9.1-1 has no problem with linux 4.13.10-1 , only with linux-lts 4.9.x

Using: 
sddm 0.16.0-1
xf86-input-libinput	0.26.0-1
xorg-server	1.19.5-1

Thanks, Bernie
Comment 2 demaio 2017-11-03 20:06:21 UTC
Created attachment 135233 [details]
libinput debug-events

Further observations: "libinput debug-events" crashes when inserting a HP Elitebook into docking station, see attachment. Internal keyboard does not work anymore after that. The touchpad and the "pointer stick" still work.

Seems to happen only with HP WMI.

Workaround on Arch Linux: Either downgrade to libinput 1.8.3 or "rmmod hp_wmi".
Comment 3 acutbal 2017-11-04 00:06:16 UTC
Hello,
I've the same issue, after upgrading libinput 1.9 on Manjaro Xfce the keyboard and the touchpad of my laptop HP G62 don't work anymore, I can't enter nor to my desktop nor TTY. Tested with kernel 4.4 and 4.9.

However, with the latest kernel 4.13 the keyboard and the touchpad work as usual.

Best regards.
Comment 4 stark.devel 2017-11-04 12:17:25 UTC
Hello,

just to confirm that I'm experiencing the same issue. I'm running Arch Linux with kernel linux-lts 4.9.60-1 on a HP ProBook 430 G4. Many people on bbs.archlinux.org report problems with HP laptops. Also, I'm running on Xorg instead of Wayland. My model has no dock station, the keyboard just doesn't work after upgrading libinput. An external USB keyboard works. Downgraded to libinput 1.8.3 and the problem is gone.

If you need any log or further info tell me!

Have a good day and thanks for all your work.

Best
Comment 5 kujaw 2017-11-04 15:58:49 UTC
Keyboard doesn't work when laptop is in docking station.
Happend few days ago, after pacman -Syu.

Laptop: HP Probook 650 G1,
kernel: 4.13.11-1-ARCH
xorg-server 1.19.5-1

Downgrading to libinput 1.8.3-1 from 1.9.1-1 helped.
Comment 6 Peter Hutterer 2017-11-06 05:18:45 UTC
*** Bug 103571 has been marked as a duplicate of this bug. ***
Comment 7 Peter Hutterer 2017-11-06 05:31:16 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1508741 is another one for reference but I can't seem to reproduce this with the evemu recordings. What I'll need is an evemu-recording for the WMI device which looks like the culprit and ideally a gdb backtrace.

evemu is independent of the libinput version, but for gdb I need 1.9. Easiest way to produce that is to git clone libinput, build it and run sudo gdb ./builddir/libinput-debug-events. No install needed. When the crash happens, type "backtracke" and attach the full gdb log here, thanks.
Comment 8 zeng.shixin 2017-11-06 16:28:19 UTC
With libinput from git commit cad73f402328897f21e6ae0cdc0e6d2500c1395d, libinput-debug-events doesn't crash, but instead it can't find the key:

~/libinput.git/build$ sudo ./libinput-debug-events --device /dev/input/event0
-event0   DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group1  cap:k
 event0   KEYBOARD_KEY      +4.10s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.12s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.25s	*** (-1) released
 event0   KEYBOARD_KEY      +4.29s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.30s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.32s	*** (-1) released
 event0   KEYBOARD_KEY      +4.36s	*** (-1) released
 event0   KEYBOARD_KEY      +4.41s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.42s	*** (-1) released
 event0   KEYBOARD_KEY      +4.55s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.63s	*** (-1) released
 event0   KEYBOARD_KEY      +4.71s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.72s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.75s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.75s	*** (-1) released
 event0   KEYBOARD_KEY      +4.83s	*** (-1) released
 event0   KEYBOARD_KEY      +4.84s	*** (-1) released
 event0   KEYBOARD_KEY      +4.87s	*** (-1) pressed
 event0   KEYBOARD_KEY      +4.96s	*** (-1) released
 event0   KEYBOARD_KEY      +5.05s	*** (-1) released
 event0   KEYBOARD_KEY     +10.13s	KEY_LEFTMETA (125) pressed
 event0   KEYBOARD_KEY     +10.14s	*** (-1) pressed
 event0   KEYBOARD_KEY     +10.32s	KEY_LEFTMETA (125) released
 event0   KEYBOARD_KEY     +10.32s	*** (-1) released
 event0   KEYBOARD_KEY     +11.44s	KEY_LEFTMETA (125) pressed
 event0   KEYBOARD_KEY     +11.45s	*** (-1) pressed
 event0   KEYBOARD_KEY     +11.59s	*** (-1) released
 event0   KEYBOARD_KEY     +11.61s	KEY_LEFTMETA (125) released
 event0   KEYBOARD_KEY     +13.46s	KEY_MUTE (113) pressed
 event0   KEYBOARD_KEY     +13.64s	KEY_MUTE (113) released
 event0   KEYBOARD_KEY     +14.24s	KEY_VOLUMEDOWN (114) pressed
 event0   KEYBOARD_KEY     +14.42s	KEY_VOLUMEDOWN (114) released
 event0   KEYBOARD_KEY     +15.24s	KEY_VOLUMEUP (115) pressed
 event0   KEYBOARD_KEY     +15.45s	KEY_VOLUMEUP (115) released
 event0   KEYBOARD_KEY     +15.76s	KEY_PREVIOUSSONG (165) pressed
 event0   KEYBOARD_KEY     +15.93s	KEY_PREVIOUSSONG (165) released
Comment 9 zeng.shixin 2017-11-06 16:29:11 UTC
Created attachment 135260 [details]
evemu log
Comment 10 Peter Hutterer 2017-11-06 22:19:36 UTC
what do you mean, it can't find the key? if you're referring to the *** that's because it's purposely hidden to avoid attaching confidential information to bugzillas. see the --show-keycodes flag to make it appear.
Comment 11 zeng.shixin 2017-11-07 01:56:15 UTC
(In reply to Peter Hutterer from comment #10)
> what do you mean, it can't find the key? if you're referring to the ***
> that's because it's purposely hidden to avoid attaching confidential
> information to bugzillas. see the --show-keycodes flag to make it appear.

My bad. I thought that was the issue causing the key event ignored.

What else info do you need? I attached my evemu log in comment #9, is that not enough?
Comment 12 Peter Hutterer 2017-11-07 04:55:48 UTC
As said in comment #7, I need the WMI device's evemu log. the keyboard looks like a normal keyboard and the evemu events basically match the ones in the debug-events output. So that keyboard isn't the source of the issue.
Comment 13 Stefano 2017-11-08 06:58:13 UTC
Hi there, yesterday try to work with git bisect to found where was introduced  the regression: this is the result

/build/.../src/libinput >>> git bisect good                                        ±[●●][1.8.901~32^2~1]
986604fd9d86e92a2f04499ca23970f440201349 is the first bad commit
commit 986604fd9d86e92a2f04499ca23970f440201349
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Sep 1 17:30:08 2017 +1000

    touchpad: if a device has a tablet mode switch, disable the touchpad
    
    On some devices with a tablet mode switch, the touchpad is inacessible when
    in tablet mode and we don't really need this except to avoid possible ghost
    touches (none have been mentioned so far). On other devices like the Lenovo
    Yoga, the touchpad points to the back of the device and it's hard to use the
    device without accidentally using the touchpad. For those, disabling the
    touchpad is the best solution.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=102408
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

:040000 040000 64ff25308cc2946b68c7493fdd0448fe814e3168 a572cd4bded6a5ec42dafa53895237c4acbbe186 M	src
:040000 040000 b18982d161fa9e787f4971bb39258b5edd17a37b d394dec756e183e20592e6ec4a831ae62f9a18e3 M	test
/build/.../src/libinput >>> 


During the process one commit introduce only the touchpad issue and keyboard still working so the regression for keyboard is another commit after this.

Hope this help.

Edit: tested in an HP Pavillon Dv6 series.

Stefano Capitani
Manjaro Linux Team
Comment 14 Peter Hutterer 2017-11-08 11:22:16 UTC
Benjamin Berg pointed me to this commit here:

https://github.com/torvalds/linux/commit/298747b7579f5bbbced793d997b333fd10a24921#diff-54f29874e2ea44548b8273ee96e20f76

Based on this it looks like the status is reported wrong (tablet mode on when it's actually off) and that causes libinput to disable the keyboard and touchpad. Could easily be verified by: a) plugging a usb mouse in, those don't get disabled and b) running evemu-record against the device with the tablet mode switch bits (the WMI hotkeys device?) and checking the switch state. If it's 1 when the device isn't in tablet mode, then we have the culprit.
Comment 15 Stefano 2017-11-08 11:45:07 UTC
Able to do this this evening.
Comment 16 zeng.shixin 2017-11-08 15:36:44 UTC
(In reply to Peter Hutterer from comment #14)
> Benjamin Berg pointed me to this commit here:
> 
> https://github.com/torvalds/linux/commit/
> 298747b7579f5bbbced793d997b333fd10a24921#diff-
> 54f29874e2ea44548b8273ee96e20f76
> 
> Based on this it looks like the status is reported wrong (tablet mode on
> when it's actually off) and that causes libinput to disable the keyboard and
> touchpad. Could easily be verified by: a) plugging a usb mouse in, those
> don't get disabled and b) running evemu-record against the device with the
> tablet mode switch bits (the WMI hotkeys device?) and checking the switch
> state. If it's 1 when the device isn't in tablet mode, then we have the
> culprit.

This is what I see on my HP Envy TouchSmart:

$ sudo ./libinput-debug-events --device /dev/input/event18 --verbose
event18 - HP WMI hotkeys: is tagged by udev as: Keyboard Switch
event18 - HP WMI hotkeys: device is a keyboard
event18 - HP WMI hotkeys: device is a switch device
-event18  DEVICE_ADDED     HP WMI hotkeys                    seat0 default group1  cap:kS
 event18  SWITCH_TOGGLE     +0.00s	switch tablet-mode state 1
^Cevent18 - HP WMI hotkeys: device removed
Comment 17 Stefano 2017-11-08 17:46:33 UTC
Created attachment 135314 [details]
libinput debug: last git commit

There is a debug on HP pavillon dv6
Comment 18 Peter Hutterer 2017-11-08 23:35:03 UTC
Does the problem go away when you update to kernel 4.12 or later?

> event18  SWITCH_TOGGLE     +0.00s	switch tablet-mode state 1

This shows that the tablet mode state is enabled. And libinput disables keyboard/touchpad when that happens, for hopefully obvious reasons. So the culprit appears to indeed be a wrong tablet mode switch. Same for attachment 135314 [details], the switch is shown as on.
Comment 19 dpaessler 2017-11-09 07:58:07 UTC
I'm jumping in here with the same problem on a HP Elitebook 8740w.
It started with libinput-1.9.0 and I'm running kernel 4.13.11 and the problem still persists.
Comment 20 Benjamin Berg 2017-11-09 10:49:45 UTC
(In reply to dpaessler from comment #19)
> I'm jumping in here with the same problem on a HP Elitebook 8740w.
> It started with libinput-1.9.0 and I'm running kernel 4.13.11 and the
> problem still persists.

Hmm, your laptop is dockable but not convertible into tablet mode right?

On dockable machines the kernel currently has to assume that it can correctly read the tablet mode state. So it could well be that this assumption is invalid and a further check whether the hardware is convertible is needed.
Comment 21 dpaessler 2017-11-09 14:33:42 UTC
(In reply to Benjamin Berg from comment #20)

> Hmm, your laptop is dockable but not convertible into tablet mode right?

That's right.
Comment 22 A Rand User 2017-11-09 15:40:45 UTC
Same problem on HP pavillion TD sleekbook 14 Touchsmart
With linux 4.9.
Solved by upgrading to linux 4.13.
Comment 23 Stefano 2017-11-09 18:02:11 UTC
Philip Muller applied the patch found herein our repo (Manjaro) and now 1.9.1 work fine in kernel 4.9.x
 
https://github.com/torvalds/linux/commit/298747b7579f5bbbced793d997b333fd10a24921

cheers
Stefano
Comment 24 Peter Hutterer 2017-11-10 00:10:22 UTC
dpaessler: can you file a new bug for your issue please? The majority of users here seem to be affected by the 2987 kernel commit. Yours will require some libinput changes, let's discuss these in a fresh bug.
Comment 25 Peter Hutterer 2017-11-14 05:39:58 UTC
based on comment 23 and other test results, I'm closing this one, it's a kernel issue.
Comment 26 Benjamin Berg 2017-11-14 15:48:08 UTC
Looks like the issue on the dockable HP notebooks might be fixed by the commit

http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commit/9968e12a291e639dd51d1218b694d440b22a917f

  platform/x86: hp-wmi: Fix tablet mode detection for convertibles

The patch didn't make it into Linus tree yet, AFAICT, but it looks like it might be fixing the issue that dpaessler is seeing.
Comment 27 dpaessler 2017-11-15 15:31:47 UTC
(In reply to Benjamin Berg from comment #26)
but it looks like it might be fixing the issue that dpaessler is seeing.

Thanks for pointing this out, that indeed fixed it for me (kernel 4.14.0). you really made my day!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.