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


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.