You are not logged in.
I'm running Arch with KDE Plasma as my graphical environment and SDDM as my greeter in a single monitor setup, and if I attempt to switch to a virtual terminal, I'm greeted with "no signal" from my monitor until I switch back. The TTYs definitely work; I forgot to install a terminal emulator and managed to blindly install konsole, and all graphical features work without issue. I have seen references to this problem before with NVIDIA hardware (I'm running an NVIDIA RTX 4070 Ti with the nvidia-open drivers). From what I understand this should have been resolved by a previous update to the drivers (version 580), but I am having the exact same issue despite being on the latest kernel (linux 6.18.5.arch1-1) and drivers (nvidia-open 590.48.01-7; nvidia-utils 590.48.01-2).
In setting up the drivers, I added nvidia, nvidia_modeset, nvidia_drm, and nvidia_udm to the modules section of mkinitcpio. Since I don't have a quiet boot and log messages are visible on tty1, I could see the difference in having them load early vs. late: the signal is lost earlier until SDDM loads. Adding and removing the KMS hook in mkinitcpio has had no effect.
I have tried to explicitly add the parameters nvidia_drm.modeset=1 and nvidia_drm.fbdev=1 to the boot parameters in /etc/default/grub, but that has had no effect either (as expected, this appears to be set by default now). The outputs of
# cat /sys/module/nvidia_drm/parameters/fbdevand
# cat /sys/module/nvidia_drm/parameters/modesetare both Y whether or not the parameters are set explicitly.
Here is a journalctl log of the current boot (https://0x0.st/PKQZ.txt); a few seconds before dumping (13:58:39) I switched to a virtual terminal. Doing so always introduces messages about /dev/i2c devices not being writable, but this appears to be a KDE complaint.
Offline
Does switching work when you try it from the sddm screen before logging in to plasma ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Does switching work when you try it from the sddm screen before logging in to plasma ?
Switching does not work in that circumstance.
Offline
So the cause lies on a lower level.
Please configure your system to boot to multi-user.target , see https://wiki.archlinux.org/title/System … _boot_into
This will give you a console login .
Don't login yet, just try Alt+Fn (n = 2,3,4,5 or 6 ) .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Fwwi
Jan 18 11:59:20 westerlund kernel: nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.
'm greeted with "no signal" from my monitor until I switch back.
How long are you waiting for this? (nvidia fb switches are notoriously slow, try to give it a minute - literally)
What mode are you running the output with, is it https://wiki.archlinux.org/title/Variable_refresh_rate capable?
Can you attach it via DP?
Offline
So the cause lies on a lower level.
Please configure your system to boot to multi-user.target , see https://wiki.archlinux.org/title/System … _boot_into
This will give you a console login .
Don't login yet, just try Alt+Fn (n = 2,3,4,5 or 6 ) .
I'll do this once I remake an arch install USB, since I'm not confident graphics will work at all in text mode. The boot log is only visible for no more than 3 seconds at startup before I'm greeted with "no signal" up until SDDM starts.
How long are you waiting for this? (nvidia fb switches are notoriously slow, try to give it a minute - literally)
What mode are you running the output with, is it https://wiki.archlinux.org/title/Variable_refresh_rate capable?
Can you attach it via DP?
Probably not more than 15 seconds; I'll give this a try.
The monitor I have it attached to is a Cooler Master GP27U which supports VRR (support is enabled in KDE; I have tried both activating and deactivating it with no change in TTY behavior). I am using HDMI 2.1 since it can't achieve its maximum resolution and frame rate (4k@144Hz) without DSC over DisplayPort, but I can try to find a DisplayPort cable for testing.
Offline
Alright, I've made a very strange discovery about this behavior. It has to do with my monitor's KVM functionality.
I use a Cooler Master GP27U, and my keyboard and mouse are plugged into the monitor's KVM USB ports. When I attempt to switch terminals with Ctrl+Alt+Fn with the keyboard that's plugged into the KVM USB, the monitor never manages to find the right video mode and goes to sleep. But if I do it with the same keyboard plugged into a USB port directly connected to the PC, the switching occurs normally.
Offline
What keyboard and mouse and do you have others?
x-ref, https://bbs.archlinux.org/viewtopic.php … 8#p2284298
Offline
What keyboard and mouse and do you have others?
x-ref, https://bbs.archlinux.org/viewtopic.php … 8#p2284298
I have tested this with both a Keychron K8 Pro and a Unicomp Classic 103 key (both plugged into the PC and into the KVM, exact same behavior with both keyboards).
Mouse is a Glorious Model O, but changing where it's plugged in has no effect either. I can try to test it with a different one.
Offline
So mouse is irrelvant?
Do you have a $5 un-special keyboard from office supply?
Notably check the journal whether either of the keyboards shows up as joystick (though I don't think there's a KVM involved in the other cases and it doesn't seem to block switching between consoles - only to return to X11)
Offline
So mouse is irrelvant?
Do you have a $5 un-special keyboard from office supply?
Notably check the journal whether either of the keyboards shows up as joystick (though I don't think there's a KVM involved in the other cases and it doesn't seem to block switching between consoles - only to return to X11)
Heh...I don't have an "ordinary" keyboard, but I've decided to systematically test the keyboards I do have on hand: the Keychron K8 Pro, the Unicomp, and a Rakk Lamm-Ang Pro, both with and without the KVM. Of these boards, the Keychron and Rakk are both "gaming" keyboards with support for features like N-key rollover, while the Unicomp has no special features (it really is just a membrane keyboard; the membrane just happens to be actuated with buckling springs rather than rubber domes). There's no evidence any of these keyboards show up as joysticks under journalctl.
* The Unicomp actually switches fine with and without the KVM.
* The Keychron K8 Pro switches with the direct connection, but not with the KVM.
* The Rakk switches with and without the KVM, but after testing this, my display was reverted to a 60 Hz mode in Plasma that cannot be increased any higher (all higher framerate modes have disappeared)! Also, it does not register all keystrokes in console mode, whereas it does in KDE (but I don't think this is relevant)
After the display was reverted to 60 Hz, all keyboards switch TTYs just fine with or without the KVM, and the switch occurs instantly. When it was operating at 144 Hz, the switch took a few seconds.
Is there a way to determine what framerate is being used in the virtual console, perhaps to set it to 144 Hz? When I ran Windows on this PC, I found that switching framerates (e.g. from Alt-Tabbing out of a game that wasn't at 144 Hz) would similarly cause a long loss of signal.
[edit] forgot the journalctl output: https://0x0.st/PZOY.txt
Last edited by brainandforce (2026-01-24 22:45:07)
Offline
Keychron is actually what showed up in all the original reports of that problem - but specifically because of the joystick device which isn't in your journal
(see https://bbs.archlinux.org/viewtopic.php … 2#p2277312 and the following posts)
As for the framerate, check the monitor OSD?
You could try to enforce a mode/rate, https://wiki.archlinux.org/title/Kernel … s_and_EDID
Is it btw. static 144Hz or https://wiki.archlinux.org/title/Variable_refresh_rate ?
Offline
Keychron is actually what showed up in all the original reports of that problem - but specifically because of the joystick device which isn't in your journal
(see https://bbs.archlinux.org/viewtopic.php … 2#p2277312 and the following posts)As for the framerate, check the monitor OSD?
You could try to enforce a mode/rate, https://wiki.archlinux.org/title/Kernel … s_and_EDIDIs it btw. static 144Hz or https://wiki.archlinux.org/title/Variable_refresh_rate ?
I'm not sure what happened, but after a reboot I can swap to the VTs with only the delay induced by the different framerate.
VRR was set to "automatic" in KDE, and I decided to test the "always" and "never" options to see what would happen. With "always" switching to VTs is reliable (though switching back to KDE is not); with "never" I have issues in both directions (including a total loss of the original graphics mode KDE was using; disconnecting and reconnecting the monitor restores it). The VTs are running at 60 Hz according to my OSD.
I don't think it's appropriate to mark this as solved since I haven't identified what caused this to be fixed. I'll still try to force 144 Hz in text mode just for consistency/faster VT switching.
Offline