[SOLVED] key press display issues for gdm on xorg

seth · 2022-12-27 16:19:50

What is true and suspicious is that "Xlib: sequence lost" messages start showing up (immediately) after GDM has closed its greeter session (which runs on a parallel X11 server)
Another thing is that this seems to be acutally an optimus system ("Dec 27 08:35:22 HOST kernel: pci 0000:01:00.0: [10de:1c8d] type 00 class 0x030200") but while the nvidia GPU is there, neitehr nvidia nor nouveau drive it and I wonder whether that throws off GDM/gnome somehow™

Cbhihe · 2022-12-28 10:56:19

Yes, this is an Optimus system (viz. 10de:1c8d), on which bbswitch and bumblebee were installed but remain inoperative. Neither any NVIDIA driver nor the substitute Nouveau driver are installed. In fact they are modprobe-blacklisted:

$ cat /etc/modprobe.d/blacklist_module.conf
blacklist nouveau
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_uvm
blacklist nvidia_modeset

The intention was that the NVIDIA GPX1050 GPU should stay cold permanently. It does and the system relies on the Intel iGPU to do its compute jobs with parallelization based on either multi-CPU load sharing or multi-threading. This Host's OS was setup that way back in late 2017 or early 2018 and has behaved well until now... FWIW:

$ pacman -Qs xf86
local/libxxf86vm 1.1.5-1
    X11 XFree86 video mode extension library
local/xf86-input-evdev 2.10.6-3 (xorg-drivers)
    X.org evdev input driver
local/xf86-input-keyboard 1.9.0-3 (xorg-drivers)
    X.Org keyboard input driver
local/xf86-input-libinput 1.2.1-1 (xorg-drivers)
    Generic input driver for the X.Org server based on libinput
local/xf86-video-fbdev 0.5.0-3 (xorg-drivers)
    X.org framebuffer video driver
local/xf86-video-vesa 2.6.0-1 (xorg-drivers xorg)
    X.org vesa video driver

$ pacman -Qs mesa
local/glu 9.0.2-3
    Mesa OpenGL utility library
local/mesa 22.3.1-1
    An open-source implementation of the OpenGL specification

I have a hard time wrapping my brain around the fact that somehow a kernel module or a graphics driver or library could be responsible for ghost key-presses, but then, what do I know ?
If you think it might be worth investing a few hours on the subject, I will. Another question I have is whether it is normal and expected for the GDM greeter session to run on a parallel X server session ? That would explain your earlier comment (in #4) "GDM starts a second X11 server." as I would interpret that as the second X server session being started as soon as user login has taken place. Is that so or am I mixing up terminology again 8-| ?

One last thing I just noted this morning is that when ghost key-presses start to manifest themselves, those "ghost key presses" seem in fact to be delayed in some way between roughly 2 and 4 seconds.Typically if the misbehaving keys are for instance "/" and SHIFT and BACKSPACE, but I keep any of those or others pressed down (in key-repeat mode), they will eventually appear on terminal, or in my Vi session, or in some Libre Office window I may have opened for testing purposes. In Vi this seems to be unrelated to the session mode: COMMAND, VISUAL, INSERT, etc,

Last edited by Cbhihe (2022-12-28 11:08:44)

Cbhihe · 2022-12-29 08:32:39

Replaced output of top in #17 with something actually readable by humans. Only 2 iterations of top included.

seth · 2022-12-29 09:25:58

Another question I have is whether it is normal and expected for the GDM greeter session to run on a parallel X server session ?

Yes. It's somewhat of a GDM pecularity.

Typically if the misbehaving keys are for instance "/" and SHIFT and BACKSPACE

Hold on, this doesn't pertain to *all* input but just specific keys??

The OP wrote:

- only 1 out of 50 random key-presses (or whatever, but a LOT of key-presses anyway) seem to materialize on screen.
- the [Enter], [Backspace], [Supr], [Alt], [AltGr], and [Shift] keys stop functioning randomly (meaning all at once or not). so do the arrow- keys.

I thought all keyboard input skip 98% of input and some keys fail entirely. Is it only some keys that skip most input while others function as desired?

Test "xev -event keyboard" whether and what events are produced there. You might face a (software) stuck modifier that causes you input shortcuts.
Those will produce KeymapNotify events rather than KeyPress/Release.

Cbhihe · 2022-12-29 14:41:14

Hold on, this doesn't pertain to *all* input but just specific keys??

No, that was just an example, out of about 82 physical keys on the laptop's integrated keyboard, the issue affects all, but I get to notice the same first keys misbehaving, soon followed by others. I think I mentioned before that the keys in my example above misbehave first, but that's probably because those are the keys I use most when typing cmds in gnome-terminal.

For instance if I try to punch in $ top -b -n2 > top.txt, it will show on terminal correctly within the first 10s or so of launching gnome-terminal. After that it may show as $ tp b 2 > tpt or something similar. A few seconds later, it may only show as $ b t or something close. So there is something gradual and time related at play, as if some queue was being hogged because an upstream consumer of that queue does not keep up or is hogged by some other process. That's also what initially had me thinking this could be the work of a key-logger...

What I also noticed of late is that I don't have to quit terminal and launch one again to ultimately to end up with a correct cmd in CLI. If on a first pass I manage, say, $ tp b 2 > tpt, then I can actually go back and correct it although it's a real pain. What I need to do is go back to insert "o" between the first "t" and "p", insert a hyphen before "b", etc. To do that I need to press the left arrow key continuously. At first nothing happens, then after about a second I get a burst of left displacements of the cursor on terminal window. If I'm lucky that brings me right to the spot where I need to enter "o". If not I need to correct the cursor placement with more left or right arrow key presses, keeping whatever key pressed down until the cursor actually moves (always burst-fashion) and ends up in the right spot. Then I do the same for the "o" character, and so forth for all missing characters. After 2 minutes of that s_, I have my terminal command correctly displayed. Pressing return requires pressing down the key ENTER continuously until it actually registers and the cmd is effectively entered. When that happens output is normal.

The output of $ xev -event keyboard is here, obtained punching in: " top -b -n1 >| top.txt "

Last edited by Cbhihe (2022-12-29 14:50:47)

seth · 2022-12-29 15:39:44

That indicates something is hogging the system and the server can't keep up processing the events.
We also know that it's limited to gnome.
Apparently there's no excessive CPU load, so maybe it's IO and in that case my money would be on tracker (gnome file index thingy)
Try to mask the service (tracker3)
https://www.linuxuprising.com/2019/07/h … acker.html

Maybe also zeitgeist (drop the package if installed)

Cbhihe · 2022-12-29 16:12:06

I systematically zap zeitgeist and the likes of it on every host I get my hands on.
I have disabled the tracking service on some machines with Gnome-flavored GUI before. Will check that one now.

Cbhihe · 2022-12-29 19:00:35

S loginctl session-status
3 - USER (1000)
Since: Thu 2022-12-29 08:47:31 CET; 10h ago
Seat: seat0; vc2
TTY: tty2
Service: gdm-password; type x11; class user
State: active
Unit: session-3.scope
├─1611 "gdm-session-worker [pam/gdm-password]"
├─1645 /usr/lib/gdm-x-session --run-script /usr/bin/gnome-session
├─1647 /usr/lib/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 7 -core
└─1727 /usr/lib/gnome-session-binary

Dec 29 19:07:35 HOST gdm-password][1611]: accountsservice: ActUserManager: updating user USER
Dec 29 19:07:35 HOST gdm-password][1611]: accountsservice: ActUserManager: sending user-changed signal for user USER
Dec 29 19:07:35 HOST gdm-password][1611]: accountsservice: ActUserManager: sent user-changed signal for user USER
Dec 29 19:07:35 HOST gdm-password][1611]: accountsservice: ActUserManager: updating user USER
Dec 29 19:08:30 HOST gdm-password][1611]: accountsservice: ActUserManager: sending user-changed signal for user USER
Dec 29 19:08:30 HOST gdm-password][1611]: accountsservice: ActUserManager: sent user-changed signal for user USER
Dec 29 19:08:30 HOST gdm-password][1611]: accountsservice: ActUserManager: updating user USER
Dec 29 19:08:31 HOST gdm-password][1611]: accountsservice: ActUserManager: sending user-changed signal for user USER
Dec 29 19:08:31 HOST gdm-password][1611]: accountsservice: ActUserManager: sent user-changed signal for user USER
Dec 29 19:08:31 HOST gdm-password][1611]: accountsservice: ActUserManager: updating user USER

$ systemctl --user mask tracker-extract-3.service tracker-miner-fs-3.service tracker-miner-rss-3.service tracker-writeback-3.service tracker-xdg-portal-3.service tracker-miner-fs-control-3.service
Created symlink /home/USER/.config/systemd/user/tracker-extract-3.service → /dev/null.
Created symlink /home/USER/.config/systemd/user/tracker-miner-fs-3.service → /dev/null.
Created symlink /home/USER/.config/systemd/user/tracker-miner-rss-3.service → /dev/null.
Created symlink /home/USER/.config/systemd/user/tracker-writeback-3.service → /dev/null.
Created symlink /home/USER/.config/systemd/user/tracker-xdg-portal-3.service → /dev/null.
Created symlink /home/USER/.config/systemd/user/tracker-miner-fs-control-3.service → /dev/null.

#### reboot

$ tracker3 reset -s -r
Found 0 PIDs…

And the result, punching in "And now what is the deal with ghost key-presses ?!" in gnome-terminal:

$ d nw wht is teda with ghost key-prsses

No change.

Last edited by Cbhihe (2022-12-29 19:11:47)

seth · 2022-12-29 22:04:39

https://gitlab.gnome.org/GNOME/gnome-sh … ssues/3369 is supposed to be fixed, but hey…
Try to run glxgears in the foreground. See what happens.

Btw, it's not in your package search results in #27 but the (dated. "Wed Nov 4 15:51:28 2020") xorg log in #25 suggests that you are/were using xf86-video-intel
Don't.

It also shows "es,jp,cn" what makes me wonder whether this is maybe related to a non-trivial (gnome) keyboard config (so try w/ only one layout configured) or some IM (eg. fcitx)

seth · 2023-01-05 21:39:33

https://bbs.archlinux.org/viewtopic.php … 7#p2077837

Cbhihe · 2023-01-09 19:59:49

@seth:
Thank you for the heads-up. I had seen the beginning of the Arch bbs thread but not the news of the fix. I have paused troubleshooting on that now idle machine due to the holiday crunch at work. Will get back to it ASAP. Tx.

Cbhihe · 2023-01-13 11:14:47

Back to it today, I initiated the host from a USB boot ISO and arch-chroot'ed in its system to perform a global package update with `# pacman -Syu ' to see if the latest libx11 package update is the solution.

The kernel was updated to 6.1.5 and I extracted the the following timeline on updates for libx11:

$ grep -i libx11 /var(log/pacman.log
[...]
[2022-12-16T19:43:24+0100] [ALPM] upgraded libx11 (1.8.2-2 -> 1.8.3-1)
[2022-12-21T15:18:51+0100] [ALPM] upgraded libx11 (1.8.3-1 -> 1.8.3-3)
[2023-01-13T11:05:59+0100] [ALPM] upgraded libx11 (1.8.3-3 -> 1.8.3-5)

Interestingly the issue I dubbed "ghost key presses" started on the first reboot following [2022-12-16T19:43:24+0100]. The latest update, today at 11:05:59 (1.8.3-3 -> 1.8.3-5) seems to have resolved the problem.... So I will mark this thread as [SOLVED].

So thank you, @seth, for the considerable time you have spent on this with me and thanks to you too, @cfr, for having chimed in ... I am aware that I am indebted to this Community for all the help I received in the past 3 months, so I will try to contribute all I can (.... time permitting :-(()

And on a side note, I'm really surprised that this issue has not caused more noise than it did. Maybe not all Archlinux hosts with a graphical interface built on an X window server was affected...

[SOLVED]

Last edited by Cbhihe (2023-01-13 11:18:52)

Arch Linux

#26 2022-12-27 16:19:50

Re: [SOLVED] key press display issues for gdm on xorg

#27 2022-12-28 10:56:19

Re: [SOLVED] key press display issues for gdm on xorg

#28 2022-12-29 08:32:39

Re: [SOLVED] key press display issues for gdm on xorg

#29 2022-12-29 09:25:58

Re: [SOLVED] key press display issues for gdm on xorg

#30 2022-12-29 14:41:14

Re: [SOLVED] key press display issues for gdm on xorg

#31 2022-12-29 15:39:44

Re: [SOLVED] key press display issues for gdm on xorg

#32 2022-12-29 16:12:06

Re: [SOLVED] key press display issues for gdm on xorg

#33 2022-12-29 19:00:35

Re: [SOLVED] key press display issues for gdm on xorg

#34 2022-12-29 22:04:39

Re: [SOLVED] key press display issues for gdm on xorg

#35 2023-01-05 21:39:33

Re: [SOLVED] key press display issues for gdm on xorg

#36 2023-01-09 19:59:49

Re: [SOLVED] key press display issues for gdm on xorg

#37 2023-01-13 11:14:47

Re: [SOLVED] key press display issues for gdm on xorg

Board footer