X.Org: Re: invoking xinput --disable [ || --enable] <device_xID> kills X
Cedric Bhihe
cedric.bhihe at gmail.com
Thu Apr 15 08:40:51 UTC 2021
Peter and all, apologies for the noise.
I had misunderstood Peter's earlier response and thought reporting on
the list was the right thing to do. I filed the issue at
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1162.
Cheers,
-cedric
___________________________________________________________
On 15/04/2021 04:34, Peter Hutterer wrote:
> please file a gitlab issue against the X server, mailing lists and email in
> general are not useful for debugging with logfiles, etc.
>
> Cheers,
> Peter
>
> On Wed, Apr 14, 2021 at 10:58:11PM +0200, Cedric Bhihe wrote:
>> @whot:
>>
>> 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:
>> http://paste.c-net.org/ProducedNorway
>> Lines
>> "#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
>> http://paste.c-net.org/EscapedElias.
>>
>> 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
>>
>> Cheers,
>>
>> -cedric
>>
>> __________________________________________________________________
>>
>> 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
>> a
>>>> 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 (3.38.2.1-1 -> 40.0-1)
>>>>
>>>> I have looked up FAQs, misc FAQs and extra FAQs and all I could on
>>>> get
>> my
>>>> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20210415/b47049f6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg/attachments/20210415/b47049f6/attachment.sig>
More information about the xorg
mailing list