[SOLVED] key press display issues for gdm on xorg

Cbhihe · 2022-12-17 21:07:21

I am on 6.0.12-arch1-1 #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux, running up to date gdm on xorg.
When using stdin in GUI, if the window currently displaying keyboard input is freshly opened and I type in, things appear to function normally and I am able to use single keys as well as key combinations on the keyboard. ü û æ € ł, etc. In random typing trials the weirdness seems to start after a few seconds. It includes:

- 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.
- if I leave a window alone I just did for about 10~12 minutes with a LO Writer's window on my GUI, some keys seem to "come back to life", e.g. [Enter], only to start malfunctioning again a few seconds afterwards.

Oddly I had no issue writing this post on bbs.archlinux.org using Mozilla Firefox.

Affected windows I tested are any app from the LO suite, tmux pty terminal tiles. Dropping to console with CTRL+ALT+F1, I could see that Console is not affected, so this is a GUI issue that does not affect at least Mozilla Firefox windows.

This appeared so random, that it looks like this system is affected by a virus of sorts.

The output of 'dmesg' is here, but I was not able to detect anything helpful there.

Currently the system is barely usable in GUI mode because of the issue. I really don't know how to start unraveling this, in particular because I have no theory to work with as to what may be causing the issue. I have re-re-read the Keyboard input wiki and other wikis referenced in it, but that did not get me anywhere.

Any nudge would really be welcome.

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

seth · 2022-12-18 09:21:08

How does

the window currently displaying keyboard

relate to

gdm on xorg

?
It would seem that the actual desktop session where the problem occurs (gnome, kde, i3, …) as well as its display server is far more relevant.

Cbhihe · 2022-12-18 15:52:45

@seth: thank you for the nudge.

I was not thinking that the windows themselves were the culprit.
Rather I think that at the center of it all is either GDM (in my HOST's case) or X.Org interacting with client windows via the X11 protocol.
From there, my various cherry-picked examples of what happens or does not happen in GUI clients windows... (I now crossed out those examples in OP above.)

In any case I don't have a theory as to why this may be happening, except for a few items I don't know how to interpret in my boot journal here, in the form of /usr/lib/gdm-x-session errors.

I thought about rolling gdm, libgdm 's installed versions back from my current 43.0-1 to 42.0+r11...-1 as of 2 months ago. But I hesitate to do this, not just because of the quantity of packages involved in the roll-back and the real possibility of breaking things, but mostly because I really don't understand how the described anomalous behavior came about.

Here is perhaps a better characterization of what happens:
- I open a Gnome terminal's window with or without tmux tiling.
- I type in whatever, e.g.: $ grep gdm /var/log/pacman.log.
- output is as expected.
- I leave that App alone to concentrate on something else. for instance this post in a different window on Firefox or whatever
- coming back to the pts a few 10s of seconds later, almost all I type on the keyboard including pressing [Enter] or the [Space] bar has gone. It never shows on terminal.
- I need to hard close the the gnome-terminal with the mouse, not with CTRL-D because that does not carry over to the terminal any longer) and start anew to be able to work with it again.
- go back to first item on this list and repeat.

Last night I reinstalled gdm to no avail (as I expected), but I was confident that that was not going to hurt anything.

Should I maybe try switching to Wayland, to eliminate X as the possible culprit ?

Last edited by Cbhihe (2022-12-29 07:52:31)

seth · 2022-12-18 17:04:37

GDM starts a second X11 server, chances that GDM is responsible for the input issues inside your desktop session on a different X11 server border zero from the other side.

For starters, you have at least ntctl, systemd-networkd and dhcpcd enabled.
Post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

and then pick one service and disable the others.

Dec 18 15:20:34 HOST firefox.desktop[2144]: Xlib: sequence lost (0x10000 > 0xd2d) in reply type 0x2!

Indicates what you perceive

Dec 18 15:20:26 HOST gnome-shell[1936]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1e00048

*might* hint at the cause.

If fixing the network config doesn't solve this, I'd first try the behavior in eg. an openbox session (started from GDM)

Cbhihe · 2022-12-18 17:44:33

After keeping only all netctl based network services (after disabling dhcpcd and systemd-networkd):

    $ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

    avahi-daemon.service                     | multi-user.target.wants
    avahi-daemon.socket                      | sockets.target.wants
    bluetooth.service                        | bluetooth.target.wants
    cronie.service                           | multi-user.target.wants
    cups.path                                | multi-user.target.wants
    cups.service                             | multi-user.target.wants
    cups.service                             | printer.target.wants
    cups.socket                              | sockets.target.wants
    dbus-org.bluez.service                   | system
    dbus-org.freedesktop.Avahi.service       | system
    dbus-org.freedesktop.home1.service       | system
    dbus-org.freedesktop.resolve1.service    | system
    display-manager.service                  | system
    docker.service                           | multi-user.target.wants
    gcr-ssh-agent.socket                     | sockets.target.wants
    getty@tty1.service                       | getty.target.wants
    gnome-keyring-daemon.socket              | sockets.target.wants
    lm_sensors.service                       | multi-user.target.wants
    netctl-auto@eth0.service                 | sys-subsystem-net-devices-eth0.device.wants
    netctl-auto-resume@wifi0.service         | sleep.target.wants
    netctl-auto@wifi0.service                | sys-subsystem-net-devices-wifi0.device.wants
    netctl-ifplugd@net0.service              | multi-user.target.wants
    netctl-ifplugd@net0.service              | sys-subsystem-net-devices-net0.device.wants
    netctl.service                           | multi-user.target.wants
    netctl-sleep.service                     | sleep.target.wants
    netctl-wait-online.service               | network-online.target.wants
    nmb.service                              | multi-user.target.wants
    p11-kit-server.socket                    | sockets.target.wants
    paccache.timer                           | timers.target.wants
    pcscd.socket                             | sockets.target.wants
    pipewire-media-session.service           | pipewire.service.wants
    pipewire-session-manager.service         | user
    pipewire.socket                          | sockets.target.wants
    postfix.service                          | multi-user.target.wants
    pulseaudio.socket                        | sockets.target.wants
    remote-fs.target                         | multi-user.target.wants
    smb.service                              | multi-user.target.wants
    sshd.service                             | multi-user.target.wants
    systemd-homed-activate.service           | systemd-homed.service.wants
    systemd-homed.service                    | multi-user.target.wants
    systemd-resolved.service                 | sysinit.target.wants
    systemd-timesyncd.service                | sysinit.target.wants
    systemd-userdbd.socket                   | sockets.target.wants
    tlp.service                              | multi-user.target.wants
    tor.service                              | multi-user.target.wants
    ufw.service                              | multi-user.target.wants
    xdg-user-dirs-update.service             | default.target.wants

After rebooting, the problem persists. Now moving toward starting an openbox session from GDM.

Cbhihe · 2022-12-20 13:12:40

Sorry for the long delay in following up. It is due to the fact that the host was air-gapped until now as a precautionary measure. There is a suspicion that the detection of a second GDM session being started from within the first, the key presses not being displayed, and two superfluous networking service daemons running (dhcpcd and systemd-networkd) may be indicative of penetration by malware ( e.g. key-logger, trojan,...?). So I have been extra busy with exploring malware detection in Linux, and in particular with discovering rkhunter (RKH) and how to use it.
Before proceeding with the openbox suggestion by @seth, I'd like to take a shot at this with RKH. Here's what I did so far followed by a noob's question before i continue:
- booted from an Iso Arch 220210 on USB,
From console, I:
- configured a special wifi access based on an ssid specific iwd config file,
- updated Pacman's db and keys,
- installed rkhunter and updated its data,
- installed lsof,
- read the sourceforge README and man pages on configuring and running RKH. The readme file reads "it may be beneficial to run RKH from a bootable medium, if a breach of security is suspected..."
The question I have before proceeding is should I bind/mount the host's volumes before chrooting in and proceeding with the RKH scan?
(My zero-experience-with-RKH concern is that chrooting in (seems inevitable) may actually allow the malware to taint the results.)

Last edited by Cbhihe (2022-12-29 07:54:11)

seth · 2022-12-20 13:41:25

two superfluous networking service daemons running (dhcpcd and systemd-networkd) may be indicative of penetration by malware

Are you absolutely positively sure that you didn't enable them?

The question I have before proceeding is should I bind/mount the host's volumes before chrooting in and proceeding with the RKH scan?

You'll need to mount them so rkhunter can scan them, chrooting would still exec the kernel from the live distro, but it also means that you're not using the clean tools and/or rkhunter will not be available in /usr/bin - so if you want to perform an offline scan, chrooting into the system would be contraprductive.

Don't freak out about the results, rkhunter throws quite some false positives, that's normal.

Unless you're absofuckinglutely sure that you didn't enable the additional network services, try openbox first.

Cbhihe · 2022-12-20 17:18:09

No, I can't be certain, but 6 hands touch that host and I for one have not made that mistake of simultaneously enabling redundant network services since the once in 2018.

As I was all set and ready, I went ahead and ran the RKH scans as reported below:

Using the iso pendrive kernel and tools, the RKH log is here. This was performed after all host's volumes except for swap were mounted, The log is identical to that of the scan on the booted pendrive only, i.e. without mounting any of the host volumes, as checked with cmd: lsblk -f...
Result: 117 files checked and 4 warnings for possible positives among them two hidden directories. This make me suspect that I may have done this wrong. I expected the log's contents to be different.

The only thing that strikes me as odd in the RKH log is the fact that by default the Arch installed sshd_config arranges for the SSH config option 'PermitRootLogin' to be "yes". I expected a more restrictive "no" or at least a conservative "forced-command-only". I learned something new AND unexpected today. :-S !

Leaving the ISO pendrive boot option behind and, instead, using the booted host's kernel and tools, the RKH log is here. This time the SSH config option 'PermitRootLogin' is unset on the host and so is the SSH Protocol V1 option.

So those results look pretty innocuous to me but I may have botched it. Not sure.

Back to starting an openbox WM session from GDM. I am not sure I did find the adequate description of the needed configuration. Is this what I need ?

Last edited by Cbhihe (2022-12-29 08:00:00)

seth · 2022-12-20 20:37:09

No, you just install openbox and select it as session in GDM. That's all.

Arch installed sshd_config aranges for the SSH config option 'PermitRootLogin' to be "yes"

The unaltered upstream default is prohibit-password.

cfr · 2022-12-21 03:28:35

Just in case, have you checked the accessibility options in KDE? Because enabling some of those (perhaps using a default keyboard shortcut) could produce symptoms something like you've described.

I think I would have a word with the other four hands, myself. While it could be an elaborate double-bluff, it is hard to think what an attacker could hope to gain from enabling conflicting network services.

Cbhihe · 2022-12-21 08:51:58

@seth: all works well with openbox as WM. There are none of the symptoms of key-presses not being displayed after a few 10s of seconds in any client window. Everything is A-ok.

(Incidentally i like the uncluttered minimalist look of openbox. It'basic.)

seth · 2022-12-21 09:15:08

Some process within the gnome session is going rogue; I'd have a look at the top of "top", since it'll likely hump the CPU itself as well.

Cbhihe · 2022-12-21 10:07:14

@cfr: do you mean key-bindings that would trigger some other DM configuration option to kick in ?
The only thing remotely KDE flavored and installed on that host is libappindicator-gtk3.
Did have a small chat with 2 or the 4 remaining hands. Even "Hello" was already a negociation. It's a "complicated" case.

@seth:
Under openbox the top items in top are: firefox, gnome-terminal-, tor, Xorg, containerd, systemd, tmux:server, systemd-resolve, kthreadd, rcu_gp, ... There is the usual fluctuation of course but firefox is always at the top and consumes 2.3 or 3% of MEM and 1 to 13% of CPU. Other processes consume less.

Just using X under GDM, I get

Tasks: 267 total, 1 running, 266 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.1 us, 0.9 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.2 hi, 0.1 si, 0.0 st
MiB Mem : 15728.6 total, 11573.4 free, 1346.0 used, 2809.3 buff/cache
MiB Swap: 17180.0 total, 17180.0 free, 0.0 used. 13682.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13794 USER 20 0 3423580 491184 254004 S 11.6 3.0 0:14.33 firefox
13501 USER 20 0 1506048 178872 122912 S 8.6 1.1 0:04.62 Xorg
14451 USER 20 0 482368 55660 41696 S 4.0 0.3 0:01.32 gnome-terminal-
13595 USER 20 0 5214988 280264 185320 S 2.3 1.7 0:03.90 gnome-shell
37 root 20 0 0 0 0 S 0.3 0.0 0:00.32 ksoftirqd/3
658 root 0 -20 0 0 0 I 0.3 0.0 0:00.07 kworker/u17:1-i915_flip
904 root 20 0 1648524 44676 23104 S 0.3 0.3 0:09.40 containerd
11276 root 20 0 0 0 0 I 0.3 0.0 0:00.19 kworker/u16:0-ext4-rsv-conversion
13122 root 20 0 0 0 0 I 0.3 0.0 0:00.24 kworker/3:1-events
16120 USER 20 0 13308 4468 3584 R 0.3 0.0 0:00.22 top
1 root 20 0 169476 14292 10084 S 0.0 0.1 0:01.94 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp

Let me know if you want to see a more complete snapshot of processes.

Last edited by Cbhihe (2022-12-27 08:47:59)

cfr · 2022-12-21 12:14:11

I don't know why I said KDE. I meant gnome would have something similar in terms of accessibility options. Enabling those can make keys behave in strange ways, but the rogue hypothesis is much more likely unless there's a clear pattern which fits.

Cbhihe · 2022-12-21 13:36:19

@cfr: thanks. all Gnome's accessibility options are off for this host (*). The question remains as to why a second instance of X11 gets launched and by what ? Why do Gecko client apps seem immune to the ghost key-presses ?

I am more than a little perplexed.

EDIT: (*) except for the "key repeat" setting, which is enabled.

Last edited by Cbhihe (2022-12-21 14:39:10)

seth · 2022-12-22 07:21:53

The interesting part would be the cpu load in your gnome session, where you experience these wild lags.

Cbhihe · 2022-12-22 13:56:21

@seth: sorry, not sure I get your meaning; I thought that that was what the last listing (above) was about. I truncated it at 13 lines, but a longer version is here. There is really nothing that goes above and beyond Thunderbird and/or Firefox in terms of "CPU-hogging". There is no significant increase of CPU activity as reported elsewhere e.g. in association with accessibility settings.

The only thing I noticed right off the bat on top, that I had not seen before, is an increase in interrupt activity ( ksoftirqd, idle_injectN, kswapd, etc...) in other words kernel management stuff that has to do with heavy CPU loads. But those processes are exposed by top as "I" (idle), so how significant is all this ?... I am not knowledgeable enough to go to the bottom of it unaided.

I would think that processes spawned by or associated to GDM go far beyond what follows:

$ ps -ef --headers | grep -v grep | grep gdm
root         706       1  0 60159 11080   0 09:12 ?        00:00:00 /usr/bin/gdm
root        1578     706  0 79274 12764   3 09:16 ?        00:00:00 gdm-session-worker [pam/gdm-password]
USER         1608    1578  0 40151  5396   7 09:16 tty2     00:00:00 /usr/lib/gdm-x-session --run-script /usr/bin/gnome-session
USER         1610    1608  3 381007 111884 4 09:16 tty2     00:13:23 /usr/lib/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3

... but in order to isolate them and calculate the corresponding CPU loads, I will need to read more on GDM and exactly how it does what it does. Am I on the right tracks ?

Last edited by Cbhihe (2022-12-29 08:31:03)

seth · 2022-12-22 14:22:27

I don't understand your focus on GDM.
GDM is your desktop manager - the thing where you enter your password.
Afaiu we found that it is irrelevant and when used to start openbox, your problem does not exist.

Only when logging into gnome (your desktop environment) you're getting those lags.
Yesno?

In that case, the process load during the gnome session (when you experience the lags) matters.

Cbhihe · 2022-12-22 14:48:40

when [GDM is] used to start openbox, your problem does not exist.

--- yes

Only when logging into gnome (your desktop environment) you're getting those lags.

--- yes

Doesn't gnome-session start the desktop using GDM ? For that reason I tended to to refer to whatever happens after USER logs in the Gnome DM as the "USER session" or in this case (wrongly) the "Gnome session". Bad habit.
So if gnome-session starts in particular gnome-shell and gnome-settings-daemon and I get well over 1250 of "sequence lost" lines at boot

gnome-terminal-server[32369]: Xlib: sequence lost (0x10000 > 0x4a40) in reply type 0x3!

what could be happening and how do I get to show process load ?

Last edited by Cbhihe (2022-12-22 14:49:41)

seth · 2022-12-22 19:33:36

Just log into a gnome session, watch your keyboard lag and look at top (maybe keep it running in a top-layered terminal)

Gdm starts any kind of session, if it's "gnome-session" it's a gnome session
That will start gnome-shell and a bunch of other stuff.

Cbhihe · 2022-12-23 11:28:40

Looking at the output of top while probing the keyboard key-presses in an Xterm for instance, really does not give me anything above and beyond the snapshot already provided earlier.

The time needed to enter the degraded behavior mode became shorter of late... Now I only have about 10s in terminal sometimes less, before I must quit the terminal and start a new one again. This carries over to any affected client app window. It's not specific to gnome-terminal.

(The time shortening is unrelated to my modifying the ~/.xinitrc file as described below.)

Following the "Xlib acting up" lead... I looked at the host's ~/.xinitirc file and commented two lines in it before rebooting the host:

dbus-update-activation-environment --systemd DISPLAY
# Import env-var DISPLAY manually, in case the absence of a display
# manager prevents the DISPLAY env-var from being correctly set.
systemctl --user import-environment DISPLAY

eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK

# Load key bindings (before calling window manager)
#xbindkeys

includes=/etc/X11/xinit/xinitrc.d
if [ -d "$includes" ]; then
    for f in "$includes/"*; do
         [ -x "$f" ] && . "$f"
    done
    unset f
fi
unset includes

# Run Gnome on Xorg session only
export XDG_SESSION_TYPE=x11
export DE="gnome"
#exec gnome-session

Lines that were commented out are the xbindkeys and the exec gnome-session lines (as shown).
Those tweaks had no effect on the issue with ghost key-presses.

Last edited by Cbhihe (2022-12-23 15:00:48)

Cbhihe · 2022-12-23 17:49:44

Apparently other reports exists and trickle in, for instance here, about the same type of error spamming the journal and about Xorg client apps crashing, hanging, becoming unresponsive or very sluggish.

The actual technical issue is well above my head but several voices out there point to a multi-threading issue messing up the a key press/release event queue perhaps by injecting stuff.
I have seen no hard evidence of that because "seeing" it would entail diving deep into code and I am no developer.

I'd like to keep working on Xorg with X11 as WM, and not switch other to another WM. Could removing and reinstalling an appropriate package group be a workaround for this problem ?
How can I try to get out of this bind ?

cfr · 2022-12-24 01:16:45

Cbhihe wrote:

I'd like to keep working on Xorg with X11 as WM, and not switch other to another WM. Could removing and reinstalling an appropriate package group be a workaround for this problem ?

X11 isn't a wm. I believe mutter is the default wm in gnome.

By the way, are you sure you want all of the netctl services? E.g. netctl-auto@eth0.service seems unusual since this kind of service is designed for wireless connections. You have two wired connections as well as wireless, is that right?

seth · 2022-12-24 16:25:55

GDM doesn't use your xinitrc, also that xinitrc would immediately terminate the session since there's no lasting process.
https://wiki.archlinux.org/title/GDM#Use_Xorg_backend

Can we please get an updated system journal (covering the problem)?

Cbhihe · 2022-12-27 11:13:09

@cfr:
(A) First the wireless service netctl-auto@eth0.service is enabled for a wired interface eth0 that was renamed early on with udev: eth0-->net0 makes no sense at all, as you noted. I disabled that. It should not have been there in the first place. That's weird.
(B) Second two wired services netctl-ifplugd@net0.service are enabled with different targets. That looks pretty strange because the host has only one wired interface, so I disabled both service before recreating the soft link (i.e. re-enabling the service). But (B), i.e. the coexistence of two instances of the same service with two different targets, somehow does not strike me as as offensive as (A).
I am so focused on getting to the bottom of those ghost key-presses, that I had not even noticed that in the output shown in #5.

... and, yes, X11 is version 11 of X the client-server comm protocol but it's many other things as well, an API, implementing X11, used by Gnome and Mutter. I'm sure I'm not the only one to be confused with terminology ... which is what comes with something that has developed over the course of 30 years and has grown beyond the expectation of many. I remember my first contact with X on now ancient Sun workstations in the early 90's. That also gives you an idea of how ancient I might be. :-|

@seth:

In the output of journalctl -b, the following entries are still there:

08:35:26 HOST gnome-shell[...]: Running GNOME Shell (using mutter 43.2) as a X11 window and compositing manager
...
08:35:27 HOST org.gnome.Shell.desktop[...]: Window manager warning: Failed to parse saved session file: Failed to open file “/var/lib/gdm/.config/mutter/sessions/10b3b9e3e615c72a0a167212652635392000000011870000.ms”: No such file or directory
...
08:35:34 HOST gnome-shell[...]: Running GNOME Shell (using mutter 43.2) as a X11 window and compositing manager

The host's /etc/gdm/custom.conf has been as shown below all along.
Xorg backend is forced to the exclusion of Wayland. I configured this way back and forgot why exactly. I did not modify anything else in GDM's configuration. Actually I'm double-checking that that has remained so, right now.

# GDM configuration storage

[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

AutomaticLoginEnable=False
AutomaticLogin=USER

[security]

[xdmcp]

[chooser]

[debug]
# Uncomment the line below to turn on debugging
#Enable=true

and here is /var/log/Xor.0.log.

Last edited by Cbhihe (2022-12-27 12:39:18)

Arch Linux

#1 2022-12-17 21:07:21

[SOLVED] key press display issues for gdm on xorg

#2 2022-12-18 09:21:08

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

#3 2022-12-18 15:52:45

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

#4 2022-12-18 17:04:37

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

#5 2022-12-18 17:44:33

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

#6 2022-12-20 13:12:40

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

#7 2022-12-20 13:41:25

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

#8 2022-12-20 17:18:09

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

#9 2022-12-20 20:37:09

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

#10 2022-12-21 03:28:35

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

#11 2022-12-21 08:51:58

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

#12 2022-12-21 09:15:08

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

#13 2022-12-21 10:07:14

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

#14 2022-12-21 12:14:11

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

#15 2022-12-21 13:36:19

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

#16 2022-12-22 07:21:53

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

#17 2022-12-22 13:56:21

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

#18 2022-12-22 14:22:27

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

#19 2022-12-22 14:48:40

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

#20 2022-12-22 19:33:36

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

#21 2022-12-23 11:28:40

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

#22 2022-12-23 17:49:44

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

#23 2022-12-24 01:16:45

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

#24 2022-12-24 16:25:55

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

#25 2022-12-27 11:13:09

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

Board footer