X.Org: Re: invoking xinput --disable [ || --enable] <device_xID> kills X
peter.hutterer at who-t.net
Thu Apr 15 02:34:12 UTC 2021
please file a gitlab issue against the X server, mailing lists and email in
general are not useful for debugging with logfiles, etc.
On Wed, Apr 14, 2021 at 10:58:11PM +0200, Cedric Bhihe wrote:
> Following up on X crashing when invoking `$ xinput --disable <device_name>`,
> I tried to isolate the error with:
> `$ grep -i -e "xorg\| X" < <(journalctl -xb) | grep -i -e "fail\|error"`
> I include what seems to be the relevant section here:
> "#3 0x00005625301421b1 FatalError (Xorg + 0x14c1b1)" just before
> 21:43.22 and
> "#3 0x000055e2520e61b1 FatalError (Xorg + 0x14c1b1)" between 21:43:34
> and 22:02:13
> correspond to the two times I reproduced the crash on that boot.
> FatalError (Xorg + 0x14c1b1)
> seems to be the indicator for the crash. It led me to the full coredump
> trace in systemd available at
> In the past few days I have seen 2 reports appear on that, essentially from
> archers running Xorg like me.
> - http://paste.c-net.org/BunksTyped
> - https://bbs.archlinux.org/viewtopic.php?id=264928
> Am 12/04/2021 um 04:35 schrieb Peter Hutterer:
> > On Sun, Apr 11, 2021 at 08:39:54PM +0200, Cedric Bhihe wrote:
> > > Hi folks,
> > >
> > > [Background info: host OS is Arch linux 5.11.12 with gdm 40.0.1 on xorg]
> > >
> > > For the past 4 days, I have this weird mix-up between issuing either of the
> > > following cmds in a `tmux` terminal:
> > >
> > > $ /usr/bin/xinput --disable <xID>
> > > or
> > > $ /usr/bin/xinput --enable <xID>
> > >
> > > where <xID> is my Touchpad xorg device ID (=14) on a Dell XPS15, obtained
> > > with
> > > $ /usr/bin/xinput --list --short
> > First note: you can use the device name, so `xinput disable "my device
> > name"` - you do not need to use the ID. This has worked for probably a
> > decade or more now.
> > > Issuing either one of the above cmds instantly kills my gdm user session,
> > > along with all that was going on in it. Next it lands me on the gdm user
> > > login frame, where I can start a new user session as if nothing had
> > > happened. Everything else seems completely normal.
> > most likely a crash in the X server, please check your journal for any
> > backtraces and file an issue against the X server (cc @whot, i.e. me) and
> > we can have a look.
> > Cheers,
> > Peter
> > > The touchpad's driver is: xf86-input-synaptics 1.9.1-2 (could not
> > > find
> > > reference to a recent update)
> > > The xorg-xinput version is 1.6.3-2, upgraded from 1.6.3-1 on 2020.05.19 (way
> > > before the issue appeared)
> > > On the other hand, gdm + the linux kernel and headers were upgraded recently
> > > (from /var/log/pacman.log):
> > > - [2021-04-09T08:29:29+0200] [ALPM] upgraded linux
> (5.11.11.arch1-1 ->
> > > 5.11.12.arch1-1)
> > > - [2021-04-09T08:29:30+0200] [ALPM] upgraded gdm (18.104.22.168-1 -> 40.0-1)
> > >
> > > I have looked up FAQs, misc FAQs and extra FAQs and all I could on
> > > get
> > > eyes on at xorg, as well as the knowledge base on StackExchange, in addition
> > > to having scanned the web, by I found absolutely no chatter on anything
> > > similar to that issue.
> > >
> > > I'm stumped in part because I've used the above cli cmds for years to
> > > activate/deactivate my laptop's touchpad on the fly (on the same box) and
> > > I
> > > never had an issue.
> > >
> > > I'm stumped and would be grateful for any pointer.
> > >
> > > PS: I have not cross posted on gdm yet. Will do so in a few days only if
> > > needed or recommended by someone deeper than me on the issue.
More information about the xorg