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.

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.

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? :)

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.

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.

Attach it anyway, it's the top part that matters here, not the runtime bits.

You want me to attach that now even though the problem isn't happening right now?

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

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.

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.

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?

(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

any success in identifying what's going on?

No, and the problem seems to have gone away. I'll re-open if I see a reproducible case again.