Bug 99777

Summary: Lid switch monitoring occasionally gives false positives, erroneously disabling the internal touchpad
Product: Wayland Reporter: Nate Graham <nate>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: medium CC: nate, peter.hutterer
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: evemu-record for the lid switch
libinput-debug-events --verbose

Description Nate Graham 2017-02-12 00:42:18 UTC
Hardware: HP Spectre x360 (Kaby Lake, late 2016)
Software: Fedora 25 + GNOME 3.22.2 + libinput 1.6.0-2.fc25

Every since libinput added lid switch support to disable the internal touchpad (in 1.6.0, I believe), I've had periodic issues with false positives disabling the touchpad. evemu-record targeting the lid switch shows that what's happening is that every so often a lid switch closed event is falsely recorded. When this happens, moving your finger on the touchpad doesn't result in any cursor motion (confirmed by evemu-record for the touchpad).

Worse, this false state persists across reboots, so when the lid switch is recorded as closed, rebooting the machine (as you might expect a novice user to do in a panic) doesn't reset the lid switch value or trigger a re-read, so the problem does not go away.

Closing and then re-opening the lid to trigger a lid switch change (confirmed with evemu-record targeting the lid switch) instantly makes the problem disappear.
Comment 1 Peter Hutterer 2017-02-12 23:39:00 UTC
right, so this device is completely broken then. easy to fix, but I'll need the dmesg, easiest if you give me an evemu-record of the lid device node.
Comment 2 Nate Graham 2017-02-13 00:34:13 UTC
Created attachment 129542 [details]
evemu-record for the lid switch

"Completely broken?" The lid switch does seem to trigger properly when the lid is actually opened and closed. I've attached the requested info.
Comment 3 Peter Hutterer 2017-02-13 00:40:44 UTC
if a switch randomly sends events when it shouldn't, I'd say that qualifies as broken, even if it works when it's actually triggered. If your keyboard did that, you'd say it was broken too, wouldn't you? :)
Comment 4 Peter Hutterer 2017-02-13 00:53:21 UTC
oh, another note here: libinput monitors the internal keyboard when the lid state is closed, so as soon as you type any key the touchpad should be enabled again. Is this not the case? Can you provide a libinput-debug-events --verbose output from when this happens, just the top bit is enough, that should show the switch->keyboard pairing.
Comment 5 Nate Graham 2017-02-13 01:18:42 UTC
Ah, that does indeed not happen. Banging on the keyboard doesn't get the touchpad moving again. I'll attach the result of `libinput-debug-events --verbose` once it happens again.
Comment 6 Peter Hutterer 2017-02-13 01:25:07 UTC
Attach it anyway, it's the top part that matters here, not the runtime bits.
Comment 7 Nate Graham 2017-02-13 01:43:04 UTC
You want me to attach that now even though the problem isn't happening right now?
Comment 8 Peter Hutterer 2017-02-13 01:50:35 UTC
yes please. if it doesn't react to keyboard events it's probably because the pairing fails. That should show up during the initialization, not at runtime.

but while I have you there, please also confirm:
* evemu-record notices EV_SW/SW_LID close events at 'random' times, i.e. when you do not close the lid
* evemu-record still sees touchpad events when the bug occurs
* the physical lid switch works correctly otherwise, so you're never stuck in a logical closed state after opening the lid.


fwiw, a software workaround for now (instead of opening the lid manually):
sudo evemu-event --type EV_SW --code SW_LID --value 0 --sync /dev/input/event0
Comment 9 Nate Graham 2017-02-13 01:53:22 UTC
Created attachment 129545 [details]
libinput-debug-events --verbose

Sure, I'm attaching it now.


* evemu-record notices EV_SW/SW_LID close events at 'random' times, i.e. when you do not close the lid
- Confirmed.

* evemu-record still sees touchpad events when the bug occurs
- Confirmed.

* the physical lid switch works correctly otherwise, so you're never stuck in a logical closed state after opening the lid.
- Confirmed.
Comment 10 Peter Hutterer 2017-02-13 02:11:09 UTC
From the log:
input device 'Lid Switch', /dev/input/event0 not tagged as input device
not using input device '/dev/input/event0'.

So whatever you're seeing is not the result of the new lid switch code, at least not in libinput. For the new lid switch code to work, you'll need a relatively recent systemd patch to tag switch devices with ID_INPUT_SWITCH. Without that, libinput will ignore the device. You can easily verify this with udevadm info /sys/class/input/event0 (for your switch device) and see if that shows up. If not, the new lid code isn't triggered.

Coincidentally, the evemu-event command above can verify this, send it with --value 1 to logically close the lid - the touchpad should still work.
Comment 11 Nate Graham 2017-02-13 02:34:07 UTC
That's odd, because evemu-record is definitely able to see lid switch events if I target event0:

################################
#      Waiting for events      #
################################
E: 0.000001 0005 0000 0001	# EV_SW / SW_LID               1
E: 0.000001 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +0ms
E: 1.132031 0005 0000 0000	# EV_SW / SW_LID               0
E: 1.132031 0000 0000 0000	# ------------ SYN_REPORT (0) ---------- +1132ms

[triggered by closing and opening the lid]



Also, `udevadm info` shows stuff:

$ udevadm info /sys/class/input/event0
P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0/event0
N: input/event0
E: DEVNAME=/dev/input/event0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0/event0
E: ID_INPUT=1
E: ID_PATH=acpi-PNP0C0D:00
E: ID_PATH_TAG=acpi-PNP0C0D_00
E: LIBINPUT_DEVICE_GROUP=19/0/5/0:PNP0C0D/button
E: MAJOR=13
E: MINOR=64
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=4970686


But you're right `sudo evemu-event --type EV_SW --code SW_LID --value 1 --sync /dev/input/event0` doesn't manage to disable the touchpad.



So... what's going on here?
Comment 12 Peter Hutterer 2017-02-13 03:17:24 UTC
(In reply to Nate Graham from comment #11)
> That's odd, because evemu-record is definitely able to see lid switch events
> if I target event0:

yes, that's expected. the kernel's handling is independent of libinput, libinput may choose not to handle certain devices. fwiw, what evemu sees is the same that libinput sees.
 
> Also, `udevadm info` shows stuff:

ID_INPUT_SWITCH is missing, that's the one thing we care about for the switch code. For other touchpads we use ID_INPUT_TOUCHPAD, etc.

> So... what's going on here?

honestly, no idea at this point. Leave libinput-debug-events running and see what happens when the touchpad disables itself. Or check the Xorg.log when this happens to see if there's anything of use.

if you leave libinput-debug-events running, I recommend applying this patch first: https://lists.freedesktop.org/archives/wayland-devel/2017-February/033065.html
Comment 13 Peter Hutterer 2017-02-27 02:23:37 UTC
any success in identifying what's going on?
Comment 14 Nate Graham 2017-02-27 04:39:26 UTC
No, and the problem seems to have gone away. I'll re-open if I see a reproducible case again.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.