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

LaptopDev · 2026-01-19 20:40:22

[update] This thread initially was about permissions to launch X without a display manager. That was resolved quickly. ... But switching VT's causes freezing with complex-hid devices and seems to be random regardless of being a motherboard IO port or not. This appears addressable in the short term by downgrading systemd to version 257. I will update this post when upstream fixes this, but will mark this as solved with the workaround for the time being.

Is there a way to launch Xorg without marking the startup script executable (`chmod +x`)?

I’m testing an isolated FVWM3 session on a secondary display (`:1`) and trying to understand what Xorg actually requires from the launch path.

Relevant logs:

```
/home/user/fvwm-xorg-test.xinit.stderr.log
https://0x0.st/PKwH.log

/home/user/fvwm-xorg-test.journal.log
https://0x0.st/PKwX.log

/home/user/fvwm-xorg-test.xinit.stdout.log
(empty)
```

This is the script I’m using to launch the session:

#!/bin/sh

TAG=fvwm-xorg-test

(
journalctl -f > "$HOME/${TAG}.journal.log" &
JPID=$!

xinit fvwm3 -- :1 -logverbose 7 
-config "$HOME/.config/xorg/xorg-fvwm.conf" 
> "$HOME/${TAG}.xinit.stdout.log" 
2> "$HOME/${TAG}.xinit.stderr.log"

kill "$JPID"
)

And this is the Xorg configuration being passed explicitly:

    Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0"
EndSection

Section "Device"
    Identifier "GPU0"
    Driver "modesetting"
    BusID "PCI:12:0:0"
EndSection

Section "Monitor"
    Identifier "Monitor0"
    Option "DPMS"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "GPU0"
    Monitor "Monitor0"
    DefaultDepth 24
EndSection

The setup works once the script is executable, but I’m trying to understand whether that requirement is intrinsic to `xinit`/Xorg, or if there’s a supported way to invoke this without relying on the executable bit.

I’m specifically interested in the mechanics here, not workarounds like wrapping it in another shell script.

Last edited by LaptopDev (Today 11:40:37)

seth · 2026-01-19 20:52:12

You cannot execute anything that doesn't have the executable bit (this isn't related to Xorg at all) but scripts specifically will just run the interpreter on themselves, so you can instead "bash /path/to/script.sh" and then script.sh doesn't have to be executable itself.
For xinit to run rootless see https://wiki.archlinux.org/title/Xinit# … nal_number

And this is the Xorg configuration being passed explicitly:

The segment there would not be a valid xorg.conf (don't copy and paste out of pagers) but in general you're typically not required nor encouraged to provide static server configurations anyway.
Xorg has decent autodetection and usually™ does the right thing automatically.

What's the point of

journalctl -f > "$HOME/${TAG}.journal.log"

?

xinit fvwm3 -- :1 -logverbose 7 
-config "$HOME/.config/xorg/xorg-fvwm.conf"

if you want to break lines in bash scripts tail the first line with a backslash "\"

I’m testing an isolated FVWM3 session on a secondary display (`:1`)

From where?
If this isn't from a console you'll have to specify a (different) VT number.

A common way to run a local test server within an existing display server is either Xephyr or a rootfull xwayland instance (you get a nested server, ie. an window with an X11 display inside)
Interventions then ideally happen via nible drop-in configlets in /etc/X11/xorg.conf.d/

LaptopDev · 2026-01-19 22:00:12

I’m testing an isolated FVWM3 session on a secondary display (`:1`).

From where?

/dev/tty1

I have systemd-logind and thought there might be some seat conflict.

What's the point of:
journalctl -f > "$HOME/${TAG}.journal.log"

Oh, I did not read that before posting. I had experimented earlier with switching back to an existing fvwm3 `xinit` instance and my system froze, so I was investigating crashing. That is beyond identifying a correct and predictable `xinit` launch.

I checked the Xserver(1) man page, which states:

Installations that run more than one window system may need to use
the xinit(1) utility instead of a display manager.

My goal is to run multiple fvwm3 instances side by side on different VTs. So that is relevant to me.

seth · 2026-01-19 22:04:29

I have systemd-logind and thought there might be some seat conflict.

No, but you've to re-use the active TTY, see the linked https://wiki.archlinux.org/title/Xinit# … nal_number

dimich · 2026-01-19 23:18:19

LaptopDev wrote:

xinit fvwm3 -- :1 -logverbose 7 -config "$HOME/.config/xorg/xorg-fvwm.conf"

xinit requires both client and server to begin with '/' or '.':

Both the client program name and the server program name must begin with a slash (/) or a period (.). Otherwise, they are treated as an arguments to be appended to their respective startup lines.

Maybe not exactly for your use case, but this may help: to run secondary Xorg session on vt8 from existing one I had to create /etc/X11/Xwrapper.config with following content:

allowed_users = anybody
needs_root_rights = yes

and then run desired client as:

$ xinit /path/to/client -- :1 -nolisten tcp -ardelay 250 -arinterval 25 vt8

LaptopDev · 2026-01-19 23:46:05

seth wrote:

I have systemd-logind and thought there might be some seat conflict.
you've to re-use the active TTY, see the linked https://wiki.archlinux.org/title/Xinit# … nal_number

Okay I am launching without errors. Can you suggest what I look at for apparent graphical freezing when I try to move to the vt after moving away? I am launching it at the current vt, but my desire is to use the other vt's/other window managers tied to them with chvt/system tty bindings. I don't know what errors to look for.

seth · 2026-01-20 08:16:37

graphical freezing when I try to move to the vt after moving away?

System journal, GPU driver/framebuffer/drm errors - nb. that nvidia is notoriously slwo on framebuffer switches, it might just take a minute…

LaptopDev · 2026-01-20 18:51:28

During a freeze, running `loginctl list-sessions` from an ssh client shows:

c1 seat0 tty2
c2 seat0 tty2

So I have two logind sessions bound to the same VT (tty2)?

When I close `c2` after closing `c1` with

loginctl terminate-session c1
loginctl terminate-session c2

My system unfreezes.

LLM suggests once "I enforce one session per VT, the issue disappears" but I am not sure how duplication occurs.

seth · 2026-01-21 10:12:47

What do your xinitrc (and xinit invoking scripts) and xserverrc look like and out of wat context do you try to spawn the second X11 server and what activates the first one (some DM?)

LaptopDev · 2026-01-21 18:03:14

I was probably creating hidden sessions on different displays, specifying different display/vt options, all while not rebooting into a fresh boot state when that duplication occurred; terminating the logind session(s) did unfreeze me in that scenario. I still got freezing now after how I outline I've changed the launch below:

seth wrote:

What do your xinitrc (and xinit invoking scripts) and xserverrc look like and out of wat context do you try to spawn the second X11 server and what activates the first one (some DM?)

My display manager `ly.service` is now disabled. My system boots into a text console from where I launch Xorg/X with "startx" (fgconsole reports it as vt1). A single Xorg pname is running, and xorg spawns without error with the default /etc/X11/xinit/xinitrc and /etc/X11/xinit/xserverrc configurations.
I still freeze moving to a different vt and back.

/usr/bin/startx
https://0x0.st/PPPm.sh
/etc/X11/xinit/xinitrc
https://0x0.st/8YCS.sh
/etc/X11/xinit/xserverrc
https://0x0.st/PPPQ.sh

ssh session for logging:
/home/user/remote-ssh_client_log.log
https://0x0.st/PPZY.log
>> /home/user/logind-freeze.log
https://0x0.st/PPZm.log
>> /home/user/kernel-freeze.log
https://0x0.st/PPZa.log

Last edited by LaptopDev (2026-01-21 18:04:55)

seth · 2026-01-21 22:47:19

*-freeze.log look uninteresting.
Before I read through it, startx is just the regular upstream default?
xserverrc critically lacks the suggested " vt$XDG_VTNR"

About freezing from a single X11 server VT switch: Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

and your Xorg log, see https://wiki.archlinux.org/title/Xorg#General for where to find it.

LaptopDev · 2026-01-22 05:39:39

seth wrote:

Before I read through it, startx is just the regular upstream default?

Yep

LaptopDev · 2026-01-22 15:22:02

/var/log/Xorg.0.log (not generated within ~/.local/ for some reason)
https://0x0.st/PP_p.0.log
journalctl -b
https://0x0.st/PP_f.txt

xserverrc has the vt variable added to it with these logs

Last edited by LaptopDev (2026-01-22 15:27:37)

seth · 2026-01-22 16:00:27

[   229.054] (**) |-->Screen "Screen0" (0)
[   229.054] (**) |   |-->Monitor "Monitor0"
[   229.055] (**) |   |-->Device "GPU0"
[   229.055] (**) Allowing byte-swapped clients

remove that config but there're no indications for major issues in the X11 log (you're running a rootless server as your user, so the log is stored under your $HOME - it could not even be written to /var/log)
The only red flag in the journal is

Jan 22 08:57:42 rog kernel: amdgpu 0000:0c:00.0: amdgpu: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22

Can you attach the output via not-hdmi?

For clarification

I still freeze moving to a different vt and back.

Moving the a different VT itself doesn't cause the freeze? Only moving back to the X11 TTY?
Can you cycle among several consoles?
Do you run a compositor (picom)?
Can you query the X11 server after initially moving away

DISPLAY=:0 xrandr -q

?

LaptopDev · 2026-01-22 19:49:28

Can you attach the output via not-hdmi?

Moving the a different VT itself doesn't cause the freeze? Only moving back to the X11 TTY?
Can you cycle among several consoles?
Do you run a compositor (picom)?
Can you query the X11 server after initially moving away
`DISPLAY=:0 xrandr -q`?

```
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 4096 x 4096
None-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1920x1080 60.00*+
```
Yes, moving to a different VT itself doesn't cause the freeze.Only moving back to the X11 TTY.
I can cycle among several consoles/TTYs, yes, so long as I do not return to the X11 TTY.
I am not running picom.

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.

I did however repeat the troubleshooting with a displayport cable now I don't see any HDMI errors.

journal-log
https://0x0.st/PPpR.txt

Unplugging the usb mouse during a freeze, though, will not break out of the freeze.

Last edited by LaptopDev (2026-01-22 19:50:33)

seth · 2026-01-22 19:53:55

I have discovered however that unplugging my usb mouse prevents freezing upon switching back to the X11 VTs.

Oh, not that shit again… https://bbs.archlinux.org/viewtopic.php … 6#p2277316
But you don't have *that* device and while your mouse is clearly schizophrenic

Jan 22 13:35:26 rog kernel: input: Razer Basilisk V3 Pro as /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.0/0003:1532:00AA.0005/input/input11
Jan 22 13:35:26 rog kernel: razermouse 0003:1532:00AA.0005: input,hidraw4: USB HID v1.11 Mouse [Razer Basilisk V3 Pro] on usb-0000:09:00.3-4/input0
Jan 22 13:35:26 rog kernel: input: Razer Basilisk V3 Pro as /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.0006/input/input14
Jan 22 13:35:26 rog kernel: razermouse 0003:1532:00AA.0006: input,hidraw5: USB HID v1.11 Keyboard [Razer Basilisk V3 Pro] on usb-0000:09:00.3-4/input2
Jan 22 13:35:26 rog kernel: input: Razer Basilisk V3 Pro as /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.1/0003:1532:00AA.0007/input/input26
Jan 22 13:35:26 rog kernel: razermouse 0003:1532:00AA.0007: input,hidraw6: USB HID v1.11 Keyboard [Razer Basilisk V3 Pro] on usb-0000:09:00.3-4/input1
Jan 22 13:35:26 rog kernel: razermouse 0003:1532:00AA.0008: hiddev97,hidraw7: USB HID v1.11 Device [Razer Basilisk V3 Pro] on usb-0000:09:00.3-4/input3

I suspect the problem is rather

Jan 22 13:35:36 rog vmware-usbarbitrator[1501]: USBGL: Failed to open '/sys/bus/usb/devices/3-4/manufacturer', error(0x2).
Jan 22 13:35:36 rog vmware-usbarbitrator[1501]: USBGL: DevID(153200aa): Failed to read manufacturer string for '3-4'.
Jan 22 13:35:36 rog vmware-usbarbitrator[1501]: USBGL: Failed to open '/sys/bus/usb/devices/3-4/manufacturer', error(0x2).

?
Do you get this w/o the vmware modules?

LaptopDev · 2026-01-22 20:39:05

Do you get this w/o the vmware modules?

Both of those? I don't see either

I ran these, and rebooted
sudo systemctl stop vmware-usbarbitrator.service
sudo systemctl disable vmware-usbarbitrator.service
sudo modprobe -r vmw_vmci

journal-log
https://0x0.st/PPOq.txt

Last edited by LaptopDev (2026-01-22 20:41:19)

seth · 2026-01-22 21:20:04

Freeze still happens w/o?
Do you have a $5 office supply mouse?

LaptopDev · 2026-01-22 21:42:12

seth wrote:

Freeze still happens w/o?
Do you have a $5 office supply mouse?

Yeah the freeze still occurs without vmware modules loaded.
Also, the $5 office supply mouse is not causing the freezing, just my razer mouse.

seth · 2026-01-22 22:01:12

"great" - does the razer mouse work w/o (I assume) openrazer?

LaptopDev · 2026-01-22 22:59:02

seth wrote:

"great" - does the razer mouse work w/o (I assume) openrazer?

Appears to. Haven't resolved freezing for it. My mouse I guess shows up as multiple usb devices, maybe x is incapable of handling a multi device device?

Last edited by LaptopDev (2026-01-22 23:00:07)

seth · 2026-01-23 10:14:29

Hardly.
Does it happen w/ https://archlinux.org/packages/extra/x8 … put-evdev/ ?
(Make sure the devices are actually handled by that)

LaptopDev · 2026-01-24 20:06:52

seth wrote:

Hardly.
Does it happen w/ https://archlinux.org/packages/extra/x8 … put-evdev/ ?
(Make sure the devices are actually handled by that)

I have added this section in xorg.conf.d
90-razer-basilisk-evdev.conf
https://0x0.st/PZpi.conf

Assuming this is confirmation my mouse devices are handled by evdev...

rog> grep -n "evdev: Razer Basilisk V3 Pro" ~/xorg-log
484:[  3243.567] (**) evdev: Razer Basilisk V3 Pro: Device: "/dev/input/event4"
485:[  3243.567] (--) evdev: Razer Basilisk V3 Pro: Vendor 0x1532 Product 0xaa
486:[  3243.567] (--) evdev: Razer Basilisk V3 Pro: Found 15 mouse buttons
487:[  3243.567] (--) evdev: Razer Basilisk V3 Pro: Found scroll wheel(s)
488:[  3243.567] (--) evdev: Razer Basilisk V3 Pro: Found relative axes
489:[  3243.567] (--) evdev: Razer Basilisk V3 Pro: Found x and y relative axes
490:[  3243.567] (II) evdev: Razer Basilisk V3 Pro: Configuring as mouse
491:[  3243.567] (II) evdev: Razer Basilisk V3 Pro: Adding scrollwheel support
492:[  3243.567] (**) evdev: Razer Basilisk V3 Pro: YAxisMapping: buttons 4 and 5
493:[  3243.567] (**) evdev: Razer Basilisk V3 Pro: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
496:[  3243.567] (II) evdev: Razer Basilisk V3 Pro: initialized for relative axes.
762:[  3247.246] (II) evdev: Razer Basilisk V3 Pro: Close
789:[  3249.227] (**) evdev: Razer Basilisk V3 Pro: Device: "/dev/input/event4"
790:[  3249.227] (--) evdev: Razer Basilisk V3 Pro: Vendor 0x1532 Product 0xaa
791:[  3249.227] (--) evdev: Razer Basilisk V3 Pro: Found 15 mouse buttons
792:[  3249.227] (--) evdev: Razer Basilisk V3 Pro: Found scroll wheel(s)
793:[  3249.227] (--) evdev: Razer Basilisk V3 Pro: Found relative axes
794:[  3249.227] (--) evdev: Razer Basilisk V3 Pro: Found x and y relative axes
795:[  3249.227] (II) evdev: Razer Basilisk V3 Pro: Configuring as mouse
796:[  3249.227] (II) evdev: Razer Basilisk V3 Pro: Adding scrollwheel support
797:[  3249.227] (**) evdev: Razer Basilisk V3 Pro: YAxisMapping: buttons 4 and 5
798:[  3249.227] (**) evdev: Razer Basilisk V3 Pro: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
801:[  3249.227] (II) evdev: Razer Basilisk V3 Pro: initialized for relative axes.

... freezing does persist with evdev.

/home/user/journal-log
https://0x0.st/PZpT.txt

/home/user/xorg-log
https://0x0.st/PZpc.txt

seth · 2026-01-25 21:56:53

Ok, let's see then what the mouse actually does.
Run

sudo udevadm monitor

plug the mouse and post the udevadm output.

You could also check evtest to see whether both "keyboard" devices of the mouse generate any input at all (and when) - one might be for additional buttons but I'm not sure about the other.
Is the mouse programmable?

LaptopDev · 2026-01-26 14:20:36

First I got the evdev nodes

rog:~$ ls -l /dev/input/by-id | grep Razer
lrwxrwxrwx 1 root root  9 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-event-mouse -> ../event6
lrwxrwxrwx 1 root root 13 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-hidraw -> ../../hidraw4
lrwxrwxrwx 1 root root  9 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-if01-event-kbd -> ../event9
lrwxrwxrwx 1 root root 13 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-if01-hidraw -> ../../hidraw6
lrwxrwxrwx 1 root root 10 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-if02-event-kbd -> ../event11
lrwxrwxrwx 1 root root 13 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-if02-hidraw -> ../../hidraw5
lrwxrwxrwx 1 root root 13 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-if03-hidraw -> ../../hidraw7
lrwxrwxrwx 1 root root  9 Jan 26 13:56 usb-1532_Razer_Basilisk_V3_Pro_000000000000-mouse -> ../mouse0

plug the mouse and post the udevadm output.

Unplug followed by plug for event-mouse:
udev-razer.log
https://0x0.st/PNrt.log

also check evtest to see whether both "keyboard" devices of the mouse generate any input at all (and when)

rog:~$ ls /dev/input/by-id/usb-1532_Razer_Basilisk_V3_Pro_*-event-kbd
/dev/input/by-id/usb-1532_Razer_Basilisk_V3_Pro_000000000000-if01-event-kbd
/dev/input/by-id/usb-1532_Razer_Basilisk_V3_Pro_000000000000-if02-event-kbd


sudo evtest /dev/input/by-id/usb-1532_Razer_Basilisk_V3_Pro_000000000000-if01-event-kbd > if01
sudo evtest /dev/input/by-id/usb-1532_Razer_Basilisk_V3_Pro_000000000000-if02-event-kbd > if02

[repeat] 1. run startx on tty1, 2. move to tty2 and run those evtest commands, 3. move back to X's tty to freeze

My system froze but neither produced output on the VT switch.

Last edited by LaptopDev (2026-01-26 21:08:24)

Arch Linux

#1 2026-01-19 20:40:22

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

#2 2026-01-19 20:52:12

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

#3 2026-01-19 22:00:12

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

#4 2026-01-19 22:04:29

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

#5 2026-01-19 23:18:19

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

#6 2026-01-19 23:46:05

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

#7 2026-01-20 08:16:37

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

#8 2026-01-20 18:51:28

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

#9 2026-01-21 10:12:47

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

#10 2026-01-21 18:03:14

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

#11 2026-01-21 22:47:19

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

#12 2026-01-22 05:39:39

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

#13 2026-01-22 15:22:02

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

#14 2026-01-22 16:00:27

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

#15 2026-01-22 19:49:28

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

#16 2026-01-22 19:53:55

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

#17 2026-01-22 20:39:05

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

#18 2026-01-22 21:20:04

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

#19 2026-01-22 21:42:12

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

#20 2026-01-22 22:01:12

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

#21 2026-01-22 22:59:02

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

#22 2026-01-23 10:14:29

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

#23 2026-01-24 20:06:52

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

#24 2026-01-25 21:56:53

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

#25 2026-01-26 14:20:36

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

Board footer