Bug 103561

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

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".

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.

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

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.

*** Bug 103571 has been marked as a duplicate of this bug. ***

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.

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

Created attachment 135260 [details]
evemu log

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.

(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?

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.

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

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.

Able to do this this evening.

(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

Created attachment 135314 [details]
libinput debug: last git commit

There is a debug on HP pavillon dv6

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.

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.

(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.

(In reply to Benjamin Berg from comment #20)

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

That's right.

Same problem on HP pavillion TD sleekbook 14 Touchsmart
With linux 4.9.
Solved by upgrading to linux 4.13.

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

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.

based on comment 23 and other test results, I'm closing this one, it's a kernel issue.

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.

(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!