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?

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

Board footer