If the event listener is added, then removed again on a lid switch on/off
event, the list is set to null. This can trigger two crashes:
* when the keyboard is removed first, the call to
libinput_device_remove_event_listener() dereferences the null pointer
* when the switch is removed first, the call to device_destroy will find a
remaining event listener and assert
https://bugzilla.redhat.com/show_bug.cgi?id=1440927
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8dcd71b395)
Sequence triggered by the xorg driver, but basically: if the touchpad is
destroyed before the lid switch, the event listener wasn't removed and an
assertion was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9d1fdb0c6d)
These tablets only ever give us a close event, the open event is broken. So
when we detect keyboard events, fix the kernel device's state by writing the
event to the fd.
We still sync the lid state manually, in case this fails and we don't get the
SW_LID through the normal event sequence. If it works fine, the real open
event will just be ignored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Extra insurance against broken lid switches. Listen to events from the
(internal) keyboard when we are logically closed. If any, assume we're open
after all and update accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the default behavior, based on the theory of hardware actually doing
the right thing. That's not always the case, follow-up patches will change
when we do the theoretically ideal thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ship a custom udev rule for the test device until systemd v333 is commonplace.
Signed-off-by: James Ye <jye836@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
