Toggling touchpad with `xinput --disable <device>` kills user session

Question

[Host running Arch linux 5.11.12-arch1-1 with gdm on Xorg.]

For years I've disabled/enabled my touchpad on the fly, directly from keyboard or cli as long as I had an active terminal session. I did this either by pressing a key combination which I bind to the execution of a small script found pretty much everywhere on the net by now, or by issuing one of two cmds central to said script, in terminal:

 $ /usr/bin/xinput --disable 14
 $ /usr/bin/xinput --enable 14

where 14 is the xorg specific device ID for my laptop's touchpad. The xorg-xinput version is 1.6.3-2, upgraded from 1.6.3-1 on 2020.05.19.

Now whenever either one of the two cmds is issued, the user session quits along with everything in it. The host recovers to present USER with a fresh gdm login screen.
Couldn't find a similar issue searching the net AND the SE knowledge base. It seems like a strange mixup between a perfectly legit xorg related cmd (xinput) and either X or gdm crashing.

Any pointerrs anyone ?

Answer 1

This is likely an X server (xorg-server) crash. The systemd journal trace of the coredump is here for two crash events on the same boot. The stack traces always include:

Stack trace of thread 3428:
#0  0x00007f1c5e6b9ef5 raise (libc.so.6 + 0x3cef5)
#1  0x00007f1c5e6a3862 abort (libc.so.6 + 0x26862)
#2  0x00005625301406ea OsAbort (Xorg + 0x14a6ea)
#3  0x00005625301421b1 FatalError (Xorg + 0x14c1b1)
#4  0x0000562530147e09 n/a (Xorg + 0x151e09)
#5  0x00007f1c5e6b9f80 __restore_rt (libc.so.6 + 0x3cf80)
#6  0x00007f1c5051efd0 libinput_device_config_send_events_get_modes (libinput.so.10 + 0x11fd0)
#7  0x00007f1c5058a139 n/a (libinput_drv.so + 0x9139)
#8  0x00007f1c5058ea19 n/a (libinput_drv.so + 0xda19)
#9  0x0000562530105a87 XIChangeDeviceProperty (Xorg + 0x10fa87)
#10 0x00005625301066af n/a (Xorg + 0x1106af)
#11 0x0000562530030195 n/a (Xorg + 0x3a195)
#12 0x00007f1c5e6a4b25 __libc_start_main (libc.so.6 + 0x27b25)
#13 0x00005625300305de _start (Xorg + 0x3a5de)

where the xf86-input-libinput driver seems to be involved in some memory corruption, ultimately causing the crash (see discussion here).

For what's worth, 2021.04.09 is when I first noted the issue. It coincided with gdm + linux kernel/headers being upgraded (from /var/log/pacman.log). It could have coincided with xf86-input-libinput major upgrade a few days earlier though:

[2021-04-06T15:52:54+0200] [ALPM] upgraded xf86-input-libinput (0.30.0-1 -> 1.0.0-1)
[2021-04-09T08:29:29] [ALPM] upgraded linux (5.11.11.arch1-1 -> >> 5.11.12.arch1-1)

EDIT: I recovered more things Gnome related, which registered an upgrade in the time window when the issue first surfaced:

$ cat /var/log/pacman.log | grep upgraded | grep -e "2021-04-06\|2021-04-07\|2021-04-08\|2021-04-09" | grep -E " g.*"

[2021-04-09T08:29:30] [ALPM] upgraded glib2 (2.68.0-5 -> 2.68.1-1)
[2021-04-09T08:29:30] [ALPM] upgraded gsettings-desktop-schemas (40.0-2 -> 40.0-3)
[2021-04-09T08:29:30] [ALPM] upgraded gnome-session (3.38.0+14+g87d92fec-1 -> 40beta+4+gd44888fb-1)
[2021-04-09T08:29:30] [ALPM] upgraded gst-plugins-bad-libs (1.18.4-3 -> 1.18.4-4)
[2021-04-09T08:29:30] [ALPM] upgraded gnome-settings-daemon (3.38.1-1 -> 40.0-1)
[2021-04-09T08:29:30] [ALPM] upgraded gnome-shell (1:3.38.4-1 -> 1:40.0-1)
[2021-04-09T08:29:30] [ALPM] upgraded gdm (3.38.2.1-1 -> 40.0-1)
[2021-04-09T08:29:30] [ALPM] upgraded gnome-clocks (40.0-1 -> 40.0-2)
[2021-04-09T08:29:30] [ALPM] upgraded gst-plugins-bad (1.18.4-3 -> 1.18.4-4)
[2021-04-09T08:29:31] [ALPM] upgraded gnome-control-center (3.38.5-1 -> 40.0-1)
[2021-04-09T08:29:31] [ALPM] upgraded gnome-notes (40.0-1 -> 40.0-2)
[2021-04-09T08:29:31] [ALPM] upgraded gnome-panel (3.38.0-1 -> 3.40.0-1)
[2021-04-09T08:29:31] [ALPM] upgraded gnome-shell-extensions (3.38.2-1 -> 40.0-1)
[2021-04-09T08:29:31] [ALPM] upgraded gnome-tweaks (3.34.1-1 -> 40.0-1)

This issue is perfectly reproducible on my platform and I filed it as a bug here. Everything seems to point to a libinput driver bug, which gets activated only when enabling/disabling specifically the touchpad with xinput.