[SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

seth · 2026-01-26 15:03:47

Hmmm…

KERNEL[143929.865467] add      /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::numlock (leds)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::numlock
SUBSYSTEM=leds
SEQNUM=7024

KERNEL[143929.875198] change   /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::numlock (leds)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::numlock
SUBSYSTEM=leds
TRIGGER=kbd-numlock
SEQNUM=7025

KERNEL[143929.875297] add      /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::capslock (leds)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::capslock
SUBSYSTEM=leds
SEQNUM=7026

KERNEL[143929.891261] change   /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::capslock (leds)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::capslock
SUBSYSTEM=leds
TRIGGER=kbd-capslock
SEQNUM=7027

KERNEL[143929.891378] add      /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::scrolllock (leds)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::scrolllock
SUBSYSTEM=leds
SEQNUM=7028

KERNEL[143929.907188] change   /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::scrolllock (leds)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.2/0003:1532:00AA.0011/input/input38/input38::scrolllock
SUBSYSTEM=leds
TRIGGER=kbd-scrolllock
SEQNUM=7029

The second keyboard has some LEDs and triggers devices for num, caps and scroll-lock.
https://wayland.freedesktop.org/libinpu … vices.html

ACTION!="remove", KERNEL=="event[0-9]*",  ENV{ID_VENDOR_ID}=="1532",   ENV{ID_MODEL_ID}=="00aa",  ENV{LED}=="7",  ENV{LIBINPUT_IGNORE_DEVICE}="1"

LaptopDev · 2026-01-26 22:10:01

I saved that udev rule and reloaded rules but I still freeze

seth · 2026-01-26 22:25:29

You'd at least have to reboot to get the device out - but I also don't know whether the LED is actually matched (or the rule disables your mouse entirely)

LaptopDev · 2026-01-28 05:54:36

seth wrote:

You'd at least have to reboot to get the device out - but I also don't know whether the LED is actually matched (or the rule disables your mouse entirely)

I rebooted and that did not work. I don't know your reasoning behind your udev rule, nor how to make one.

Chatgpt suggested this:

# Razer Basilisk V3 Pro
# Ignore keyboard interface if02 (USB interface 1.2)
# This interface creates LED devices and wedges Xorg on VT switch-back

ACTION!="remove", SUBSYSTEM=="input", \
  KERNELS=="3-4:1.2", \
  ATTRS{idVendor}=="1532", \
  ATTRS{idProduct}=="00aa", \
  ENV{LIBINPUT_IGNORE_DEVICE}="1"

So I tried it, but it didn't work. Then I tried this...

# Razer Basilisk V3 Pro
# Ignore both USB keyboard interfaces (if01, if02)
# These are not real keyboards and can wedge Xorg on VT switch-back

ACTION!="remove", SUBSYSTEM=="input", \
  ENV{ID_VENDOR_ID}=="1532", \
  ENV{ID_MODEL_ID}=="00aa", \
  ENV{ID_USB_INTERFACE_NUM}=="01|02", \
  ENV{LIBINPUT_IGNORE_DEVICE}="1"

...and it didn't stop the freezing either.

I have no knowledge for discerning what is relevant or irrelevant matching parameters. And there is complexity for me cause multiple devices and layers and stuff.

Maybe a regression in my brain power but I believed and followed new advice from chatgpt to remove razermouse out of kernel modules to restore standard kernel usb driver handling to bypass razermouse specific issues, but freezing still occurs.

Last edited by LaptopDev (2026-01-28 06:00:31)

seth · 2026-01-28 09:50:53

Freeze aside, you primarily want to check whether the devices are still created.
The first chatgpt suggestion is unsurprisingly nonsense.

ACTION!="remove", KERNEL=="event[0-9]*",  ENV{ID_VENDOR_ID}=="1532",   ENV{ID_MODEL_ID}=="00aa",  ENV{ID_INPUT_KEYBOARD}=="1",  ENV{LIBINPUT_IGNORE_DEVICE}="1"

should ignore all razer "keyboards" but might cost you some mouse buttons.

seth · 2026-01-28 09:55:15

According to https://bbs.archlinux.org/viewtopic.php … 0#p2285010 it should™ be sufficient to ignore the devices in the xorg config…

LaptopDev · 2026-01-29 22:27:18

I have these configurations and have updated hwbd and udev and rebooted but freezing persists:

/etc/udev/hwdb.d/99-razer-basilisk.hwdb
https://0x0.st/PqHh.hwdb

/etc/X11/xorg.conf.d/10-ignore-razer-keyboard.conf
https://0x0.st/PqHF.conf

chatgpt suggests a /etc/X11/xorg.conf.d/00-no-logind.conf to disable logind VT management for Xorg:

Section "ServerFlags"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
EndSection

seth · 2026-01-29 22:35:28

MatchProduct "Razer Basilisk V3 Pro Keyboard"

Does that actually match any of the deivces in

xinput list

LaptopDev · 2026-01-29 22:48:01

seth wrote:

Does that actually match any of the deivces in
xinput list

no

rog:~$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ HA086-M USB Keyboard Consumer Control   	id=9	[slave  pointer  (2)]
⎜   ↳ Razer Basilisk V3 Pro                   	id=12	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Power Button                            	id=7	[slave  keyboard (3)]
    ↳ HA086-M USB Keyboard                    	id=8	[slave  keyboard (3)]
    ↳ HA086-M USB Keyboard System Control     	id=10	[slave  keyboard (3)]
    ↳ C-Media Electronics Inc. USB Audio Device	id=11	[slave  keyboard (3)]
    ↳ Generic USB2.0 Device                   	id=13	[slave  keyboard (3)]
    ↳ Eee PC WMI hotkeys                      	id=14	[slave  keyboard (3)]
    ↳ HA086-M USB Keyboard Consumer Control   	id=15	[slave  keyboard (3)]

So I changed it to "Razer Basilisk V3 Pro" But still freezing

seth · 2026-01-29 23:04:37

That only matches a pointer device - it would seem the keyboard doesn't show up anyway?
What does your xorg log currently look like? (w/o 10-ignore-razer-keyboard.conf)

Edit: one more thing - sure it's not the "HA086-M USB Keyboard" ?
This thing only shows up in this thread - on the whole wide internet.

Last edited by seth (2026-01-29 23:05:33)

LaptopDev · 2026-01-29 23:29:59

It's not the HA086-M USB keyboard

The keyboard doesn't show up I think cause of a udev rule blocking it from earlier

LaptopDev · 2026-01-30 03:31:26

Same issue with a wired logitech g502 hero mouse

seth · 2026-01-30 07:57:50

I have discovered however that unplugging my usb mouse prevents freezing upon switching back to the X11 VTs. If I unplug the mouse, and then switch to an X11 VT, it will not freeze.
Also, the $5 office supply mouse is not causing the freezing, just my razer mouse.

Have you ever *tried* not replacing that keyboard (along the logitech mouse)
Razer and Logitech mice are rather common, your keyboard is extremely uncommon, this is a rare incident and the other occasions were down to the keyboard and blocking the non-mouse parts of the mouse has no impact.
My money is on the keyboard or some other usb device or their interaction.

lsusb -tv

Also, for clarification, this is still w/ startx and twm/xterm??

LaptopDev · 2026-01-30 08:33:46

Have you ever *tried* not replacing that keyboard (along the logitech mouse)

I have tried a different keyboard I have tested a keytronic and a perixx keyboard (not sure if it's the same keyboard you've been suspicious of) with the razer and logitech both and both mice cause the freeze..

lsusb -tv

https://0x0.st/PqZh.txt

Also, for clarification, this is still w/ startx and twm/xterm??

I am using startx with fvwm now.

Last edited by LaptopDev (2026-01-30 08:49:23)

LaptopDev · 2026-01-30 08:53:53

Is there no way to specifically ignore seating the fake keyboard while keeping the mouse's other devices with a hwdb rule?

seth · 2026-01-30 13:42:27

Is there no way to specifically ignore seating the fake keyboard while keeping the mouse's other devices with a hwdb rule?

The keyboard doesn't show up I think cause of a udev rule blocking it from earlier

sudo libinput list-devices | grep -A5 Device:

Long term this isn't a solution anyway, we can't have VT switching fail because of a slightly weird mouse being attached.
And there's probably something else or this would show up way more often

Switching among non-X11 VTs (console or wayland) is fine?
You might want to strace X11 to see what's going on there
~/.xserverrc

#!/bin/sh
exec strace -tt -o /tmp/xorg.strace /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR

/tmp/xorg.strace will probably end up being humongous - you might want to gzip it for the upload

LaptopDev · 2026-01-31 01:12:22

sudo libinput list-devices | grep -A5 Device:

libinput_cmd
https://0x0.st/Pqed.txt

exec strace -tt -o /tmp/xorg.strace /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR

xorg.strace.gz
https://0x0.st/Pq2m.gz

seth · 2026-01-31 13:47:19

libinput is for the logitech mouse, do you have any udev rule for that as well?

Device:                  Logitech G502 HERO Gaming Mouse Keyboard
Kernel:                  /dev/input/event10
Id:                      usb:046d:c08b
Group:                   6
Seat:                    seat0, default
Capabilities:            keyboard pointer

The strace is mostly uninteresting

19:08:22.316635 write(6, "(**) Logitech G502 HERO Gaming M"..., 69) = 69
19:08:22.316659 write(6, "[   161.837] ", 13) = 13
19:08:22.316681 write(6, "(**) Logitech G502 HERO Gaming M"..., 73) = 73
19:08:22.316704 write(6, "[   161.837] ", 13) = 13
19:08:22.316732 write(6, "(**) Logitech G502 HERO Gaming M"..., 72) = 72
19:08:22.316789 epoll_wait(3 <unfinished ...>) = ?
19:09:54.049820 +++ killed by SIGKILL +++

After returning to the X11 server it logs the mouse and then tries to poll events - and just hangs in the poll until you kill it - this probably has nothing directly to do w/ the X11 server and might just be a race condition.
Back to square #1

https://bbs.archlinux.org/viewtopic.php … 7#p2269507
Check the udev info and in doubt untag the devices as keyboards entirely :\

Smells like this might be a systemd/udev regression

LaptopDev · 2026-02-02 01:24:12

seth wrote:

Check the udev info and in doubt untag the devices as keyboards entirely :\

Sorry, how would I untag them as keyboards again?

Also, I noticed that the stream deck mk.2 causes this same issue.

LaptopDev · 2026-02-02 04:13:16

Conclusion
- Root cause was hardware topology, not Xorg, logind, libinput, or HID drivers
- The top/front case USB hub (USB-A + USB-C, case-mounted) cannot reliably handle composite HID devices (LED mice, Stream Deck, etc.)
- Rear motherboard USB ports, including rear USB-C, work correctly with the same devices
- Using the case hub triggered VT switch freezes due to broken composite HID handling

Clarification / Apology
- I assumed unplugging external docks eliminated USB topology variables
- I incorrectly treated the top-mounted case ports as equivalent to motherboard I/O
- That assumption led to unnecessary analysis of higher layers and prolonged the thread

Takeaway
- Use rear motherboard USB ports for complex/composite HID devices
- Avoid case front/top USB hubs for anything beyond simple HID

LaptopDev · 2026-02-02 23:34:22

Issue re-opened, the motherboard IO apparently did not resolve the issue and it has returned.

LaptopDev · 2026-02-02 23:40:39

any way to quickly just downgrade systemd to see if it fixes the issue?

seth · 2026-02-03 15:25:39

https://wiki.archlinux.org/title/Arch_L … ne_package - but the non-deterministic behavior here is concerning, do you have USB related options in your UEFI settings?

LaptopDev · 2026-02-03 22:08:22

seth wrote:

the non-deterministic behavior here is concerning, do you have USB related options in your UEFI settings?

Apparently so, I dumped my bios settings:
my_current_bios_conf_setting.txt
https://0x0.st/Pb0W.txt

Chatgpt thinks these are relevant:

Legacy USB Support [Enabled]
XHCI Hand-off [Enabled]
USB [Auto]
USB Device Enable [Enabled]
USB power delivery in Soft Off state (S5) [Enabled]
ErP Ready [Disabled]

full reply https://0x0.st/Pb04.txt

seth · 2026-02-03 22:22:27

Try to disable "Legacy USB Support"

The last two should™ only matter when the system is powered off and I've no idea what "USB Device Enable" is supposed to be and "USB [Auto]" is meaningless w/o the non-auto options.
The UEFI will likely have some context help, explaining the settings - otherwise you may find explanations in the manual.

Arch Linux

#26 2026-01-26 15:03:47

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#27 2026-01-26 22:10:01

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#28 2026-01-26 22:25:29

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#29 2026-01-28 05:54:36

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#30 2026-01-28 09:50:53

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#31 2026-01-28 09:55:15

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#32 2026-01-29 22:27:18

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#33 2026-01-29 22:35:28

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#34 2026-01-29 22:48:01

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#35 2026-01-29 23:04:37

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#36 2026-01-29 23:29:59

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#37 2026-01-30 03:31:26

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#38 2026-01-30 07:57:50

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#39 2026-01-30 08:33:46

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#40 2026-01-30 08:53:53

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#41 2026-01-30 13:42:27

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#42 2026-01-31 01:12:22

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#43 2026-01-31 13:47:19

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#44 2026-02-02 01:24:12

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#45 2026-02-02 04:13:16

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#46 2026-02-02 23:34:22

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#47 2026-02-02 23:40:39

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#48 2026-02-03 15:25:39

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#49 2026-02-03 22:08:22

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

#50 2026-02-03 22:22:27

Re: [SOLVED] Xorg freezing on VT switching 'cause of complex-hid devices

Board footer