Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

ColinVortex · 2026-05-26 08:21:50

Hello guys, this week I set up a PC with Linux for the first time in about 10 years.
I did my best to follow all the instructions from the wiki and eventually figured almost everything out

My setup is as follows:
- KDE-Plasma Desktop Environment running on Wayland
- Proprietary NVIDIA 580 DKMS driver from the AUR as recommended by the wiki, since I got an old Pascal GPU (modeset and fbdev are enabled)

Still, I'm experiencing a problem: when I switch into tty (e.g. Ctrl+Alt+F2/F3/F4), everything works fine. Switching between different TTY's also works fine. But switching back to the desktop (F1) results in signal loss on both of my monitors.
Blindly switching back to tty works but it takes almost a minute for the video to come back. Desktop only works again after system reboot (at least I have yet to try bringing it back by restarting some service).

journalctl -b -1 -p 3

outputs: https://paste.c-net.org/SayonaraCouncil

journalctl -b -1

outputs: https://paste.c-net.org/DecisiveTickets

I witnessed that the log says it's a bug in the kernel driver but I figured the issue seems to be similar to https://bbs.archlinux.org/viewtopic.php?id=313491 so I wanted to check if there is a possibility to fix this on my end.

seth · 2026-05-26 12:04:37

Mai 26 09:17:25 Gaming-PC systemd-logind[707]: The system will hibernate now!
Mai 26 09:17:25 Gaming-PC systemd[1]: Starting NVIDIA system hibernate actions...
Mai 26 09:17:25 Gaming-PC hibernate[4512]: nvidia-hibernate.service
Mai 26 09:17:25 Gaming-PC logger[4512]: <13>May 26 09:17:25 hibernate: nvidia-hibernate.service
Mai 26 09:17:26 Gaming-PC systemd[1]: nvidia-hibernate.service: Deactivated successfully.
Mai 26 09:17:26 Gaming-PC systemd[1]: Finished NVIDIA system hibernate actions.
Mai 26 09:17:26 Gaming-PC systemd[1]: nvidia-hibernate.service: Consumed 1.192s CPU time over 1.256s wall clock time, 643.7M memory peak.
Mai 26 09:17:26 Gaming-PC systemd[1]: Starting System Hibernate...
…
Mai 26 09:18:30 Gaming-PC systemd-sleep[4581]: System returned from sleep operation 'hibernate'.
Mai 26 09:18:30 Gaming-PC kernel: PM: hibernation: hibernation exit
Mai 26 09:18:31 Gaming-PC systemd[1]: systemd-hibernate.service: Deactivated successfully.
Mai 26 09:18:31 Gaming-PC systemd[1]: Finished System Hibernate.
…
Mai 26 09:18:32 Gaming-PC suspend[4751]: nvidia-resume.service
Mai 26 09:18:32 Gaming-PC systemd[1]: nvidia-resume.service: Deactivated successfully.
Mai 26 09:18:32 Gaming-PC systemd[1]: Finished NVIDIA system resume actions.
Mai 26 09:19:09 Gaming-PC org_kde_powerdevil[1076]: [  4792][294.250843]    attr_name:       NVIDIA i2c adapter 4 at 1:00.0
Mai 26 09:19:12 Gaming-PC kernel: NVRM: GPU at PCI:0000:01:00: GPU-5cf78763-6313-21c6-4f26-cb9666f8cd8a
Mai 26 09:19:12 Gaming-PC kernel: NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000004 00000080 00000000 00000005 0000000d
Mai 26 09:19:15 Gaming-PC kernel: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.

Is hibernation a critical element in this?

Mai 26 09:14:10 Gaming-PC lowntfs-3g[612]: Mounted /dev/sda1 (Read-Write, label "HDD", NTFS 3.1)

Is there a parallel windows installation?

https://bbs.archlinux.org/viewtopic.php?id=313491 is supposed to be fixed

Mai 26 09:14:10 Gaming-PC kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  580.159.04  Wed Apr 29 17:01:05 UTC 2026

but does using the software cursor avoid this?

ColinVortex · 2026-05-26 12:51:37

Is hibernation a critical element in this?

No, it also happens after clean boot. I previosly had problems with booting after hibernation but fixed it by enabling video memory preservation.

Is there a parallel windows installation?

Yes there is. Fast start is disabled on windows.

but does using the software cursor avoid this?

Unfortunately not.

I also found a new symptom: after signal loss (first monitor turns off, the second one freezes) I managed to get into TTY again and reboot from there but during the plymouth splash screen the second monitor froze again and the first one showed a static image of the desktop session from the state that it frozes in before the reboot.
Log: https://paste.c-net.org/CorsageBands

seth · 2026-05-26 14:33:32

Seems related, https://github.com/NVIDIA/open-gpu-kern … ssues/1115

1. is this also a problem w/ only one output attached?
2. is this a problem when disabling the GSP, https://wiki.archlinux.org/title/NVIDIA … P_firmware
3. is this a problem w/ plasma/X11 ?

ColinVortex · 2026-05-26 16:45:02

seth wrote:

Seems related, https://github.com/NVIDIA/open-gpu-kern … ssues/1115
1. is this also a problem w/ only one output attached?
2. is this a problem when disabling the GSP, https://wiki.archlinux.org/title/NVIDIA … P_firmware
3. is this a problem w/ plasma/X11 ?

1. surprisingly no, connecting only DP or DVI solves the issue
2. disabling GSP brought back the signal but it still remains frozen
3. I haven't tried using X11 yet

I'm also wondering if it could be related to the spam of i2c errors in my logs

seth · 2026-05-26 19:42:45

1. surprisingly no, connecting only DP or DVI solves the issue

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

2. disabling GSP brought back the signal but it still remains frozen

Can you ssh into the system or otherwise kill kwin_wayland at this point?

i2c spam is all

Mai 26 14:36:16 Gaming-PC org_kde_powerdevil[1113]: [  1238][ 15.923403] Open failed for /dev/i2c-1, errno=EACCES(-13): Permission denied in file i2c_bus_core.c near line 433

You can try to add yourself to the i2c group and hopefully that will silence powerdevil, but I doubt that this will have any impact on the problem at hand.

Next to X11 you could also try some other wayland compositor (weston or labwc)

ColinVortex · 2026-05-27 14:46:59

Output of the for-loop: https://paste.c-net.org/BalancedOprah

I will try to restart kwin_wayland via ssh this evening.

Regarding the compositor: I still haven't really understood the whole architecture of wayland but wouldn't replacing kwin with weston cause the plasma desktop to break?

Last edited by ColinVortex (2026-05-27 14:55:38)

seth · 2026-05-28 06:11:04

You'd start weston *instead* of plasma - there's no "replacing", wayland is highly fragmented.

One monitor is VRR capable 1440p@144 and the other one is 1080p@60
Can you test to disable VRR in the AOC monitor (it's OSD settings) and run both at 1080p@60 ?

ColinVortex · 2026-05-28 15:48:04

Thank you seth, I made a big step closer to the root of the problem.
The thing is, there is no option to disable VRR in my monitor's OSD. Disabling it through plasma settings does not appear to change anything because upon applying, the display doesn't turn black for a second and still show "FreeSync" in the OSD's input signal information (which, under windows, it only did when VRR was in fact enabled).
But despite that, the issue is gone now.
Do you have an idea what could cause this or of this is really a bug in the driver atp?

You'd start weston *instead* of plasma - there's no "replacing", wayland is highly fragmented.

Since I'm relying on the setup a bit, I don't really want to risk breaking the desktop environment right now

seth · 2026-05-28 18:14:28

Disabling it through plasma settings … the issue is gone now.

Is that a hard correlation? (Enabling VRR support in plasmas settings restores the previous issue)?

kscreen-doctor
qdbus6 org.kde.KWin /KWin supportInformation

might show the difference.
Also see "kscreen-doctor --help" on whether it allows you to toggle VRR for outputs.

ColinVortex · 2026-05-28 18:18:20

Hard correlation, yes. Confirmed it earlier.

Your command states "Adaptive Sync: Never" when disabled and "always" when enabled

seth · 2026-05-28 19:10:35

seth wrote:

Also see "kscreen-doctor --help" on whether it allows you to toggle VRR for outputs.

The interesting question is whether you can "fix" the problem this way after the fact (so generally keep VRR enabled for that output)

ColinVortex · 2026-05-29 06:30:38

Enabling VRR with kscreen-doctor results in the same issue

seth · 2026-05-29 06:38:36

That's expectable, the plan was rather to see if you can use VRR, switch to a TTY, "oh no, can't return to desktop!", disable VRR from the console, successfully return to KDE (and re-enable it there)

ColinVortex · 2026-05-29 06:54:12

I see.
Tried that, but kscreen-doctor refuses to run in TTY (could not connect to display and an error regarding qt).

Also, the issue appeared right now even with VRR disabled.
After running

kscreen-doctor -o

in TTY, switching back to desktop is not possible.
This is reproducable for me

Last edited by ColinVortex (2026-05-29 06:57:41)

Roken · 2026-05-29 10:44:16

I was having a problem switching to TTY. I thought this was maybe a problem introduced with the 610 drivers, but it could be older. I had always had:

nvidia_drm.modeset=1 nvidia_drm.fbdev=0

as kernel parameters. Changing to fbdev=1 has fixed it. I realise that your problem is slightly different, but it can't hurt to try.

ColinVortex · 2026-05-29 12:24:18

Hi, thanks for your help.
But fbdev is already enabled since I set up the system because the wiki recommends to do so.
I also added it to the kernel command line, just to be sure, and confirmed with

cat /sys/module/nvidia_drm/parameters/fbdev

Last edited by ColinVortex (2026-05-29 12:24:43)

seth · 2026-05-29 14:54:46

Tried that, but kscreen-doctor refuses to run in TTY (could not connect to display and an error regarding qt).

You'll have to import some relevant environment (QT_QPA_PLATFORM / WAYLAND_DISPLAY / DISPLAY) however

Also, the issue appeared right now even with VRR disabled.

so #11 was a fluke, it actually doesn't relate to the VRR setting?

ColinVortex · 2026-06-05 06:27:46

I was a bit busy the last few days.

so #11 was a fluke, it actually doesn't relate to the VRR setting?

No, the following strange behavior occurs: disable VRR in Plasma GUI settings OR via kscreen-doctor while in desktop mode --> everything works as expected. TTY-switching without problems.
Enabling VRR via the mentioned ways --> problem occurs.
And also: VRR disabled on desktop, switching to TTY, try to run kscreen-doctor there (without success, cause the variables you mentioned aren't imported) --> no luck switching back to desktop

seth · 2026-06-05 20:44:34

Just running (a failing) kscreen-doctor undoes the success that disabling VRR usually have??
"Strange" is actually putting that mildly…

Is this also the case for random other commands, eg. trying (and failing) to run konsole or something like that?
What about innocuous commands like "top" or "ls"?
What if you're polling the edid?

for OUT in /sys/class/drm/card*; do cat $OUT > /dev/null;  done

ColinVortex · 2026-06-08 08:06:35

I had some time to do some more testing.
First I installed weston. Disabled VRR in KDE Plasma system settings GUI. Then I did the following:
Switch to TTY -> run htop -> switch to plasma possible -> another TTY -> successfully run "weston", desktop environment appears -> back to console TTY -> run "konsole" (failed as expected) -> switching to plasma AND weston NOT possible anymore (screen just freezes and still shows the TTY, but pressing the combination for the TTY makes it responsive again) -> run "sudo systemctl restart plasmalogin.service -> switch to plasma possible again, weston still dead. Reboot.

Pulling the EDID though does not cause any trouble.

I'm really not sure what to make of that.

sudo journalctl -b -1

https://paste.c-net.org/ItchingPuddy

There are also some strange artifacts appearing on my 1440p monitor, I'll attach two photos. These also appear during boot, since I installed the system

Last edited by ColinVortex (2026-06-08 08:19:10)

tekstryder · 2026-06-08 11:00:38

ColinVortex wrote:

There are also some strange artifacts appearing on my 1440p monitor

That's expected behavior if you've multiple monitors of disparate resolutions.

See:

• https://bbs.archlinux.org/viewtopic.php?id=311682
• https://forums.developer.nvidia.com/t/n … /238007/40
• https://forums.developer.nvidia.com/t/l … ion/357667

tl;dr, you can fire a systemd oneshot service to fbset the desired framebuffer resultions during boot if the small viewport/artifacts bothers you.

ColinVortex · 2026-06-08 13:46:37

Thank you @tekstryder

I'm a bit confused now. Should simpledrm be blacklisted via kernel command line?
Right now I have

root=PARTUUID=25f9041f-5f15-4c3c-9cae-47c51721cd41 rw initrd=intel-ucode.img initrd=initramfs-%v.img add_efi_memmap nvidia_drm.modeset=1 nvidia_drm.fbdev=1 acpi_enforce_resources=lax resume=UUID=013cfd10-407a-48d6-9768-1b59d7d676ad resume_offset=17270784

tekstryder · 2026-06-08 14:10:45

I was just jumping into this thread for the viewport aspect

ColinVortex wrote:

Should simpledrm be blacklisted via kernel command line?

No, you show by the existence of the viewport that you're either successfully using the Nvidia driver or Nouveau.

Either way, they've assumed control of the framebuffer.

ColinVortex wrote:

Right now I have

nvidia_drm.modeset=1 nvidia_drm.fbdev=1

You can get rid of both of those. They are the driver defaults long time now.

Have you tried eliminating KDE and any Display Manager from the equation?

E.g... can you switch TTY between console-launched sessions of Weston (TTY1) and Sway (TTY2) for example?

seth · 2026-06-08 14:21:54

Also/or try to remove drkonqi - konsole doesn't fail, it aborts, triggering drkonqi - makes me wonder whether that does something to your session…

Arch Linux

#1 2026-05-26 08:21:50

Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#2 2026-05-26 12:04:37

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#3 2026-05-26 12:51:37

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#4 2026-05-26 14:33:32

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#5 2026-05-26 16:45:02

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#6 2026-05-26 19:42:45

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#7 2026-05-27 14:46:59

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#8 2026-05-28 06:11:04

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#9 2026-05-28 15:48:04

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#10 2026-05-28 18:14:28

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#11 2026-05-28 18:18:20

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#12 2026-05-28 19:10:35

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#13 2026-05-29 06:30:38

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#14 2026-05-29 06:38:36

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#15 2026-05-29 06:54:12

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#16 2026-05-29 10:44:16

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#17 2026-05-29 12:24:18

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#18 2026-05-29 14:54:46

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#19 2026-06-05 06:27:46

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#20 2026-06-05 20:44:34

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#21 2026-06-08 08:06:35

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#22 2026-06-08 11:00:38

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#23 2026-06-08 13:46:37

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#24 2026-06-08 14:10:45

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

#25 2026-06-08 14:21:54

Re: Video Output Failure on nvidia-580xx-dkms on TTY --> Desktop switch

Board footer