X.Org: Re: invoking xinput --disable [ || --enable] <device_xID> kills X

[Cedric Bhihe]

@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/20210414/e8b46f69/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/20210414/e8b46f69/attachment.sig>