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.



Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Reply via email to