[615.71.09 regression] DisplayPort link never re-established after monitor DPMS sleep — connector marked Zombie, flush mode fails, no signal until phy

Graphics / Linux Linux
, ,
1

Summary

On 615.71.09 the driver fails to bring a DisplayPort link back up after the monitor
powers down via DPMS. The monitor briefly reports “DisplayPort”, then “no input signal”,
and returns to sleep. The machine stays fully alive. Only physically unplugging and
replugging the cable restores a picture — no reboot required, and in one instance a
replug on the same socket was not enough and the cable had to be moved to a different
DisplayPort connector on the GPU.

610.57.04 does not have this problem. Same machine, same cable, same monitor, same
port — only the driver differs.

It is not the physical connector. Reproduced on two different DisplayPort sockets on
the same GPU (DP-4 and DP-5), with the same cable.

Recovery is getting harder with each occurrence. First failure: one replug restored
the picture. Second: three replugs failed and the cable had to be moved to a different
socket. Third: four replugs before a picture returned.

By default the driver logs nothing at all when this happens: no Xid, no NVRM error,
no warning. The errors below only appear with nvidia_modeset debug=1, which may be why
this does not seem to have been reported before.

System
GPU RTX 5080 (Blackwell), 0000:01:00.0
Driver 615.71.09, open kernel modules
Kernel 7.2.4-ogc3.1.fc44.x86_64
OS Bazzite 44.20260914 (Fedora 44 base, ostree)
Desktop KDE Plasma 6.7.5, KWin Wayland
Monitor Samsung Odyssey G61SD OLED, 2560x1440 @ 240 Hz, DSC + FEC enabled
Connector card2-DP-4, later card2-DP-5 — reproduces on both

Note: this is a Wayland session (KWin), so the pinned guidance about
startx -- -logverbose 6 does not apply and no Xorg log exists. The
nvidia-bug-report.log.gz was generated while the fault was still active.

Steps to reproduce

  1. Single DisplayPort monitor, DSC + FEC active (2560x1440 @ 240 Hz here).
  2. Let the display power down through normal DPMS idle timeout (KDE PowerDevil,
    TurnOffDisplayIdleTimeoutSec=120). The monitor drops HPD when it sleeps.
  3. Wake it with mouse or keyboard input.
  4. Monitor briefly shows “DisplayPort”, then “no input signal”, then sleeps again.

Reproduces on every attempt on 615.71.09; never on 610.57.04.

Log (nvidia_modeset debug=1)

Cycle as the monitor enters DPMS sleep:

14:28:22.751  DP2xCONN> Notify Attach Begin (Head 3, pclk 1116530 (KHz) raster 2896 x 1608  257 bpp, DSC 1, FEC 1)
14:28:22.751  DP2xCONN> DSC Mode = SINGLE
14:28:22.751  ERROR: DP2xCONN> SST-Flush mode should not be called when head is not attached. Returning early without enabling flush
14:28:22.851  DPCONN> Notify Attach End
14:28:23.553  WARNING: DP> AuxChCtl Failing, if a device is connected you shouldn't be seeing this
14:28:23.553  WARNING: DPCONN> Zombie? :  1 000000008bd7d68d
14:28:25.840  ERROR: Failed to write bw allocation control: 0
14:28:25.843  DP> HPD v1.4
14:28:25.843  DPCONN> Rebuild possible link rate configurations
14:28:25.843  WARNING: DP> OUI Noncompliance! Sink is DP 1.2 and is required to implement
14:28:25.903  ERROR: Invalid DisplayID2 version                       [repeats ~20x]
14:28:27.495  DP-CONN> Edid read complete: Manuf Id: 0x2d4c, Name: Odyssey G61SD
14:28:27.495  ERROR: DP2xEVO> Enabling flush mode failed!
14:28:27.495  ERROR: DP2xCONN> Set flush mode phase 1 failed
14:28:27.495  WARNING: DPCONN> Zombie? :  0 000000008bd7d68d
14:28:27.495  DP-CONN> NotifyDetectComplete
14:28:27.533  DP2xCONN> Notify Attach Begin (Head 3, pclk 1116530 (KHz) raster 2896 x 1608  257 bpp, DSC 1, FEC 1)
14:28:27.533  ERROR: DP2xEVO> Enabling flush mode failed!
14:28:27.533  ERROR: DP2xCONN> Set flush mode phase 1 failed

The wake attempt 20 seconds later produces a byte-identical sequence, on the same
connector pointer 000000008bd7d68d.

Observations

  1. The first error contradicts itself: during Notify Attach Begin (Head 3, ...) the
    driver reports in the same millisecond that no head is attached.
  2. The connector is flagged Zombie? : 1 and then Zombie? : 0, same pointer, both cycles.
  3. The sink is present and responding throughout — the EDID read succeeds and
    correctly identifies the panel (Name: Odyssey G61SD). This is not an absent or
    unresponsive monitor.
  4. Every subsequent modeset fails at Enabling flush mode failed! / Set flush mode phase 1 failed, so no signal ever reaches the panel.
  5. The bad state persists across retries and survives HPD re-assertion; only a physical
    replug clears it.

Not a hang

Initially mistaken for a system freeze. It is not. A journal capture writing a heartbeat
every 2 seconds with fsync per line shows no gap whatsoever across the failure:

14:28:20.813  14:28:22.815  14:28:24.835  14:28:26.847  14:28:28.870  14:28:30.874
14:28:32.878  14:28:34.879  14:28:36.881  14:28:38.882  14:28:40.884  14:28:42.885

Workaround

Disable DPMS display power-off entirely. Not a fix, just avoids the code path.

Relation to open-gpu-kernel-modules PR #1359

PR #1359 (“Allow
DisplayPort detach bookkeeping when the sink is unplugged”) is in the
same area — stale DP bookkeeping under the HPD guards added in 615 — but appears to be a
different bug: it is triggered by physically power-cycling the monitor, its symptom is a
specific mode failing to return, and it patches the detach path, whereas this failure
begins during an attach and results in no signal at all. Mentioning it in case they share
a root cause.

nvidia-bug-report.log.gz is attached, captured automatically while the fault was
live (the script was armed in advance to fire on the first Set flush mode phase 1a failed line, since the screen is dead at that point and nothing can be typed). It
contains 36 Set flush mode phase 1 failed, 28 Zombie? and 12 SST-Flush mode shoulda not be called when head is not attached entries, with nvidia_modeset debug=1 active.

nvidia-bug-report.log.gz (664.4 KB)

2

Author of the PR here, the only reason it mentions power cycling the monitor is because I don’t use any auto-sleep feature on my monitor and always manually power cycle it.

The issue is also possible to reproduce by swapping from non-DSC 60hz mode to a mode that requires DSC, without any monitor sleep or power cycling involved, at least on my monitor.

The issue occurs because the driver detaching the monitor fails to clear its state “in memory” in the driver. That stale state can then prevent switching to or restoring a DSC mode on the same port. On my setup, switching to a mode that doesn’t require DSC, such as 60 Hz, restores the picture ( although it doesn’t necessarily clear the stale driver state).

You could test this on your system by swapping to a mode that does not require DSC (e.g. 4k@60hz or lower on DP 1.4), rebooting your computer, then swapping to 240hz to see if the monitor connection fails to re-establish. If that’s the case I’m fairly certain the PR solves your issue.

3

Thanks for the reply, and sorry - I didn’t run the test you asked for. I went for the
boring fix instead and moved the monitor to HDMI, and the problem is simply gone. Two
sleep/wake cycles so far, clean, same 615.71.09, same GPU, same panel.

Which isn’t surprising on its own, since HDMI never touches the DP library. With
nvidia_modeset debug=1 the HDMI modesets only produce HdmiPacketLibrary lines - not a
single DP2xCONN/DPCONN/flush-mode message. What I did find interesting is that the DDC
disconnect/reconnect churn is gone too. On DP that storm showed up before every single
failure; on HDMI the connector just stays “connected” straight through the sleep.

But the reason I’m posting is that why HDMI behaves differently here seems to back up
what you’re saying about DSC.

This panel (Odyssey G61SD) has DP 1.4 and an HDMI 2.1 input capped at FRL5:

DP 1.4 HBR3 → ~25.9 Gbps usable (8b/10b)
HDMI 2.1 FRL5 → 4x10 = 40 Gbps raw, ~35.6 usable (16b/18b)

1440p240 over DP: raster 2896x1608, 1116.53 MHz → 26.8 Gbps at 8bpc.
Over budget, so DSC isn’t optional. Log agrees: “DSC 1, FEC 1”.
1440p240 over HDMI: raster 2720x1525, ~996 MHz → 23.9 Gbps at 8bpc. Comfortably
inside budget, so there’s no reason for the driver to turn DSC on.

So the two inputs on this monitor happen to differ in exactly the variable you suspect.
Same panel, same GPU, same driver, same refresh rate - one is forced into DSC, the other
isn’t, and only the DSC one breaks.

4

Confirmed same issue. Im not yanking the cables though so for me its only reboot that fixes it.. And never letting the monitor to sleep..

6

You might wanna use a HDMI cable if you got an oled monitor. Never letting it go to sleep is painful, and the issue doesn’t reproduces on HDMI.

7

Ran into the same issue. I was living with the 30 second wake times on the 610 driver with DP2.1, but since the upgrade I am forced to restart every time the monitor goes to sleep, as it never wakes.

I tried switching to DP 1.4, and in that mode it never deasserts HPD during standby. Seems like an issue with DPMS resume.

According to the compositor everything seems to be working fine. The monitor is re-added, kscreen-doctor reports the connector is connected, userspace sees everything is normal, and I can’t seem to tell a working wake from a broken one from outside of the driver. The monitor wakes, finds no stream and sleeps again.

I am gonna roll back to 610 until this is sorted.

System: RTX 5090, nvidia-open 615.71.09, kernel 7.2.6 (CachyOS), KDE Plasma 6.7.5 Wayland. Monitor: Samsung Odyssey G95NC 57", firmware M-C9557GGPA-1008.2, 7680x2160@240 HDR over DP 2.1.

8

NVIDIA-KDE-DP-Fehlerlog.txt (5.7 KB)

Title:
NVIDIA 615.71.09 + KDE Plasma Wayland: DisplayPort connector changes during software display switching

System:

  • CachyOS x86_64
  • NVIDIA GeForce RTX 2070
  • NVIDIA driver/userspace: 615.71.09-1
  • NVIDIA open kernel modules
  • Kernel: 6.18.52-1-cachyos-lts (problem reproduces here; 7.2.6 also installed)
  • KDE Plasma: 6.7.5
  • KWin: 6.7.5
  • KScreen: 6.7.5
  • Session: Wayland

Problem:
When changing a DisplayPort monitor’s enabled/disabled state through KDE/Wayland,
the physical display can disappear and reappear under a different logical DRM
connector. The monitor may then show 640x480, corrupted/“rainbow” output, or
black screen.

This is reproducible with ONLY ONE physical monitor connected, so the issue does
not depend on multi-monitor interaction.

The saved KDE display layout is not the main problem. kscreen-doctor
disable → enable can sometimes restore the display temporarily.

Important reproduction detail:
During a software display switch, a 0.2-second DRM status watcher captured:

11:54:45.639
DP-1 disconnected
DP-2 connected
DP-5 connected
DP-6 connected

11:54:45.851
DP-2 disconnected
DP-5 connected
DP-6 connected

~1.7 seconds later
DP-1 connected
DP-2 disconnected
DP-5 connected
DP-6 connected

So the DRM connector state itself changes; this does not look like KWin merely
renaming an unchanged output.

At the same time / during the failure, the kernel log contains:

nvidia-modeset: ERROR: GPU:0: nvHandleCpEventDeferredWork: displayId 0x20000 invalid
nvidia-modeset: ERROR: GPU:0: nvHandleCpEventDeferredWork: displayId 0x10000 invalid
nvidia-modeset: ERROR: GPU:0: nvHandleCpEventDeferredWork: displayId 0x40000 invalid
nvidia-modeset: ERROR: GPU:0: nvHandleCpEventDeferredWork: displayId 0x8000 invalid

The affected display can still be reported as “connected” by KScreen and can
still expose its normal modes, but the actual output may be corrupted or black.

Other observations:

  • Reproduces on the 6.18.52 LTS kernel, so it is not specific to kernel 7.2.6.
  • Multiple DP outputs can reproduce it.
  • HDMI is comparatively stable.
  • kscreen-doctor output.DP-X.disable followed by output.DP-X.enable can restore
    the display temporarily.
  • EDID files under /sys/class/drm did not provide useful data, so this was not
    treated as proof of an EDID failure.
  • The kwinoutputconfig.json layout itself appears valid.
  • nvidia-settings is not useful for diagnosing this Wayland/KWin issue.

Driver comparison:
I attempted to downgrade the NVIDIA userspace packages from 615.71.09 to
610.57.04 using cached packages. Pacman correctly refused because the installed
CachyOS NVIDIA-open kernel packages require exactly nvidia-utils=615.71.09.
I therefore did NOT force a --nodeps downgrade and did NOT change the kernel.

There are already reports of 615.71.09 DisplayPort/Wayland regressions, including
reports involving nvHandleCpEventDeferredWork … displayId … invalid and cases
where reverting to 610.57.04 restored display functionality.

Question:
Does this look like a known 615.71.09 NVIDIA DRM/KMS/DisplayPort regression?
Is there a known workaround for KDE/KWin Wayland that avoids changing the kernel
or installing a different NVIDIA kernel module?

I can provide the complete journal, KScreen output and the detailed test log if
needed.

9

I think I’m having a similar issue.

I made this post on the Fedora forums about a monitor wake up issue. My PC is multi monitor, but the new (replacement) monitor is a 240Hz, 2.1 DisplayPort OLED monitor which has been failing to ‘fully’ wake up back up on PC wake.

KDE acknowledges the monitor being connected and correctly identifies it but doesn’t render anything to the monitor. It’s completely black. The other monitors work normally so I’m able to access KDE display settings and change the Hz of the new monitor to get it to reset and start to render normally again.

My post has more detail. Please let me know if I can provide anymore data. Thanks.

Fedora44,
NVIDIA GeForce RTX 5080,
NVIDIA-SMI 615.71.09,
KMD Version: 615.71.09,
CUDA UMD Version: 13.4

10

Same issue for me I think, I can’t wake up the computer anymore. Even pluging in a secondary keyboard on the computer doesn’t wake it up, while I can hear the notification sound that the computer can use it.

Draft report for NVIDIA (Linux forum / bug report)

Framed as observations + a reproducible path + an open question.
It does not prescribe a fix — root-cause analysis is left to the maintainers.
Before posting: check current driver release notes / known issues for a matching
“Pageflip timed out” / “raster lock timeout” DP-link-recovery fix, and state what
was ruled out. Redact anything sensitive (none expected here).

Title

DP link not recovered after DPMS screen-off on RTX 4070 Ti (open 615.71.09, Wayland/KWin): “Lost display notification” + “SLI raster lock timeout exceeded”, display stuck until reboot

Summary

On a Dell U4025QW driven over DisplayPort, after the monitor has had the hermes DP
input deselected for an extended period (multi-input monitor switched to another
PC), switching back to the hermes input does not restore output. The GPU and the
rest of the system keep running (SSH stays responsive), but the display pipeline
never recovers and the input stays at “no signal / DP in standby” until a reboot.
No NVRM: Xid is logged. Reproduced on two separate days (2026-09-23, 2026-09-24).

Environment

  • GPU: GeForce RTX 4070 Ti (AD104), PCI 0000:01:00.0
  • Driver: NVIDIA open kernel module 615.71.09
  • Kernel: 7.2.4 (Fedora atomic / Bazzite base), nvidia-drm.modeset=1, nouveau blacklisted
  • Compositor: KDE Plasma / KWin on Wayland
  • Monitor: Dell U4025QW, DisplayPort direct, 5120x2160 @120 Hz, HDR + wide color gamut enabled, VRR = Automatic
  • No suspend-to-RAM involved (see below)

Observed symptoms

Kernel log at the time of failure:

nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
nvidia-modeset: ERROR:   GPU:0: SLI raster lock timeout exceeded

Compositor log, repeating roughly once per second while stuck:

kwin_wayland: Pageflip timed out! This is a bug in the nvidia-drm kernel driver

Additional observations:

  • The system is not suspending: there are no PM: suspend entry / PM: resume
    events in the journal; the machine stays up and reachable over SSH throughout.
  • No NVRM: Xid messages are emitted.
  • While stuck, the DRM connector still reports a software-nominal state
    (status=connected enabled=enabled dpms=On) and the compositor still lists the
    output as enabled — yet no scanout reaches the monitor.
  • The failure is specific to waking after a long DPMS-off period. Switching the
    monitor’s input to this GPU and back works reliably shortly after a fresh boot;
    the problem only manifests after the display has been off for a long time.

Steps to reproduce (as observed)

  1. RTX 4070 Ti driving a DisplayPort monitor at 5120x2160@120 under KWin/Wayland.
    Monitor is a Dell U4025QW with multi-input; a second PC is on another input.
  2. The monitor’s hermes DisplayPort input is left deselected for hours (user
    manually viewing the other PC — e.g. overnight). No system suspend occurs on
    hermes (verified: no PM: suspend in the journal; SSH stays up throughout).
  3. Switch the monitor back to the hermes DisplayPort input.
  4. Output does not return; kernel logs “Lost display notification” then
    “SLI raster lock timeout exceeded”; KWin loops on “Pageflip timed out”.

Observed on two separate days:

  • 2026-09-23: Lost display 07:56, raster lock 07:58.
  • 2026-09-24: monitor USB grape dropped 02:33, reconnected 08:02 on switch-back,
    Lost display 08:10, raster lock 08:12.

Notable: the failure occurs with VRR disabled (kscreen Vrr: Never, persistent
across reboot) and without any DPMS screen-off (Plasma screen-off disabled), so
neither VRR nor DPMS is the trigger — it is the long input deselection + reselection.

Recovery attempts that did NOT work (no new kernel log lines were produced):
forcing DPMS on, disabling/re-enabling the output, restarting the display manager,
power-cycling the monitor, and re-plugging the DisplayPort cable. Only a reboot
restored output (confirmed repeatedly).

Question for the maintainers

Given the “Lost display notification” followed by “SLI raster lock timeout
exceeded” with no Xid, and that the connector/atomic state still looks nominal
in software while no pageflip ever completes — what is the expected path for
nvidia-drm to re-establish the DP link / re-lock the raster after a DPMS-off on
this configuration, and what additional data (e.g. nvidia-bug-report.sh output,
specific modeset/drm debug logging) would help you reproduce and trace it?

Data available on request

  • Full dmesg / kernel journal for the affected boot.
  • journalctl --user-unit plasma-kwin_wayland around the event.
  • nvidia-bug-report.sh output.
  • Monitor EDID and mode list (kscreen output listing).

===== TIMESTAMP =====
Thu Sep 24 09:30:25 CEST 2026
run-as-uid=1000 gfx-user=manu gfx-uid=1000 runtime=/run/user/1000

===== KSCREEN OUTPUTS (KDE) =====
Output: 1 DP-3 5b53ba12-b3aa-4e17-8dd0-bd5233a85fb2
enabled
connected
priority 1
DisplayPort
replication source:0
Modes: 1:2560x1080@60.00! 10:3840x2160@50.00 11:3840x2160@29.97 12:3840x2160@25.00 13:3840x2160@23.98 14:2560x1440@59.95 15:2048x1152@60.00 16:1920x1200@59.88 17:1920x1080@60.00 18:1920x1080@59.94 19:1920x1080@50.00 2:5120x2160@120.00* 20:1600x1200@60.00 21:1680x1050@59.95 22:1280x1024@75.03 23:1280x1024@60.02 24:1280x800@59.81 25:1152x864@75.00 26:1280x720@59.94 27:1280x720@50.00 28:1024x768@75.03 29:1024x768@60.00 3:5120x2160@59.94 30:800x600@75.00 31:800x600@60.32 32:720x576@50.00 33:720x480@59.94 34:640x480@75.00 35:640x480@59.94 36:640x480@59.93 4:5120x2160@60.00 5:5120x2160@29.97 6:5120x2160@30.00 7:4096x2160@59.94 8:3840x2160@59.94 9:3840x2160@60.00
Custom modes: None
Geometry: 0,0 5120x2160
Scale: 1
Rotation: 1
Overscan: 0
Vrr: Never
RgbRange: unknown
HDR: enabled
SDR brightness: 360 nits
SDR gamut wideness: 0%
Peak brightness: 604 nits, overridden with: 570 nits
Max average brightness: 604 nits
Min brightness: 0.2051 nits
HDR color profile source: EDID
HDR ICC profile: none
Wide Color Gamut: enabled
ICC profile: none
Color profile source: sRGB
Color power preference: prefer accuracy
Brightness control: supported, set to 63% and dimming to 100%
DDC/CI: allowed
Color resolution: unknown
Allow EDR: unsupported
Sharpness control: unsupported
Automatic brightness: unsupported
Auto Rotate Policy: incapable
Adaptive backlight modulation: unsupported

===== KWIN / PLASMA / COMPOSITOR PROCESSES =====
PID %CPU %MEM ELAPSED COMMAND
3173 3.1 0.3 10:24 kwin_wayland
3377 0.0 0.1 10:23 Xwayland
3440 1.2 0.5 10:23 plasmashell

===== DRM CONNECTOR STATUS + dpms =====
card1-DP-1 status=disconnected dpms=Off enabled=disabled
card1-HDMI-A-1 status=disconnected dpms=Off enabled=disabled
card1-Writeback-1 status=unknown dpms=On enabled=disabled
card2-DP-2 status=disconnected dpms=On enabled=disabled
card2-DP-3 status=connected dpms=On enabled=enabled
card2-DP-4 status=disconnected dpms=On enabled=disabled
card2-HDMI-A-2 status=disconnected dpms=On enabled=disabled

===== FRAMEBUFFER BLANK =====

===== RECENT KERNEL DRM/i915/nvidia/usb (last 10 min) =====
Sep 24 11:19:42 bazzite kernel: usbcore: registered new interface driver usbhid
Sep 24 11:19:42 bazzite kernel: x86/amd: Previous system reset reason [0x00200800]: ACPI power state transition occurred
Sep 24 11:19:42 bazzite kernel: usb 1-2: new full-speed USB device number 2 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-2: new high-speed USB device number 2 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-2: New USB device found, idVendor=0e8d, idProduct=0608, bcdDevice= 1.00
Sep 24 11:19:42 bazzite kernel: usb 3-2: New USB device strings: Mfr=5, Product=6, SerialNumber=7
Sep 24 11:19:42 bazzite kernel: usb 1-2: New USB device found, idVendor=1a86, idProduct=5722, bcdDevice= 1.00
Sep 24 11:19:42 bazzite kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 24 11:19:42 bazzite kernel: usb 4-5: new SuperSpeed USB device number 2 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 4-5: New USB device found, idVendor=0bda, idProduct=0411, bcdDevice= 0.04
Sep 24 11:19:42 bazzite kernel: usb 4-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-5: new high-speed USB device number 3 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-5: New USB device found, idVendor=0bda, idProduct=5411, bcdDevice= 0.04
Sep 24 11:19:42 bazzite kernel: usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 4-5.1: new SuperSpeed USB device number 3 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 4-5.1: New USB device found, idVendor=0bda, idProduct=0411, bcdDevice= 0.04
Sep 24 11:19:42 bazzite kernel: usb 4-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-6: new high-speed USB device number 4 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-6: New USB device found, idVendor=0bda, idProduct=5483, bcdDevice= 1.04
Sep 24 11:19:42 bazzite kernel: usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-5.1: new high-speed USB device number 5 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-5.1: New USB device found, idVendor=0bda, idProduct=5411, bcdDevice= 0.04
Sep 24 11:19:42 bazzite kernel: usb 3-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-8: new full-speed USB device number 6 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-8: New USB device found, idVendor=0b05, idProduct=19af, bcdDevice= 1.00
Sep 24 11:19:42 bazzite kernel: usb 3-6.1: new high-speed USB device number 7 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 24 11:19:42 bazzite kernel: usb 3-6.1: New USB device found, idVendor=0bda, idProduct=5483, bcdDevice= 3.04
Sep 24 11:19:42 bazzite kernel: usb 3-6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-5.3: new full-speed USB device number 8 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usbcore: registered new interface driver system76-io
Sep 24 11:19:42 bazzite kernel: usb 3-5.3: New USB device found, idVendor=058f, idProduct=9540, bcdDevice= 1.20
Sep 24 11:19:42 bazzite kernel: usb 3-5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-11: new full-speed USB device number 9 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-11: New USB device found, idVendor=1e71, idProduct=2007, bcdDevice= 2.01
Sep 24 11:19:42 bazzite kernel: usb 3-6.2: new high-speed USB device number 10 using xhci_hcd
Sep 24 11:19:42 bazzite kernel: usb 3-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 24 11:19:42 bazzite kernel: usb 3-6.2: New USB device found, idVendor=0bda, idProduct=5483, bcdDevice= 4.06
Sep 24 11:19:42 bazzite kernel: usb 3-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:42 bazzite kernel: usb 3-5.4: new full-speed USB device number 11 using xhci_hcd
Sep 24 11:19:43 bazzite kernel: usb 3-5.4: New USB device found, idVendor=0c4b, idProduct=9102, bcdDevice= 0.01
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.1: new full-speed USB device number 12 using xhci_hcd
Sep 24 11:19:43 bazzite kernel: usb 3-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.1: New USB device found, idVendor=04d9, idProduct=a09f, bcdDevice= 2.32
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:43 bazzite kernel: usb 3-6.2.2: new full-speed USB device number 13 using xhci_hcd
Sep 24 11:19:43 bazzite kernel: usb 3-6.2.2: New USB device found, idVendor=1050, idProduct=0407, bcdDevice= 5.43
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.2: new full-speed USB device number 14 using xhci_hcd
Sep 24 11:19:43 bazzite kernel: usb 3-6.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.2: New USB device found, idVendor=0c45, idProduct=8513, bcdDevice= 1.05
Sep 24 11:19:43 bazzite kernel: usb 3-6.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] ATOM BIOS: 102-RAPHAEL-008, build: 612127 , ver: 032.019.000.008.000000, 2022/09/26
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] Detected VRAM RAM=512M, BAR=512M
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] RAM width 128bits DDR5
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] GART: num cpu pages 262144, num gpu pages 262144
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] PCIE GART of 1024M enabled (table at 0x000000F41FC00000).
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] Loading DMUB firmware via PSP: version=0x05003300
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] use_doorbell being set to: [true]
Sep 24 11:19:44 bazzite kernel: usb 3-6.2.4: new high-speed USB device number 15 using xhci_hcd
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] Display Core v3.2.384 initialized on DCN 3.1.5
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] DP-HDMI FRL PCON supported
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] DMUB hardware initialized: version=0x05003300
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] HDMI-A-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] DP-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
Sep 24 11:19:44 bazzite kernel: usb 3-6.2.4: New USB device found, idVendor=0bda, idProduct=1101, bcdDevice= 1.01
Sep 24 11:19:44 bazzite kernel: usb 3-6.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] Registered 4 planes with drm panic
Sep 24 11:19:44 bazzite kernel: [drm] Initialized amdgpu 3.64.0 for 0000:11:00.0 on minor 1
Sep 24 11:19:44 bazzite kernel: amdgpu 0000:11:00.0: [drm] Cannot find any crtc or sizes
Sep 24 11:19:44 bazzite kernel: [drm] pre_validate_dsc:1746 MST_DSC dsc precompute is not needed
Sep 24 11:19:44 bazzite kernel: usb 3-6.1.5: new high-speed USB device number 16 using xhci_hcd
Sep 24 11:19:44 bazzite kernel: usb 3-6.1.5: New USB device found, idVendor=0bda, idProduct=1100, bcdDevice= 1.01
Sep 24 11:19:44 bazzite kernel: usb 3-6.1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 11:19:44 bazzite kernel: nvidia-nvlink: Nvlink Core is being initialized, major device number 506
Sep 24 11:19:44 bazzite kernel: nvidia 0000:01:00.0: enabling device (0002 → 0003)
Sep 24 11:19:44 bazzite kernel: nvidia 0000:01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none
Sep 24 11:19:45 bazzite kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64 615.71.09 Release Build (akmods@) Mon Sep 21 01:11:04 UTC 2026
Sep 24 11:19:45 bazzite kernel: nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for x86_64 615.71.09 Release Build (akmods@) Mon Sep 21 01:09:46 UTC 2026
Sep 24 11:19:45 bazzite kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
Sep 24 11:19:45 bazzite kernel: [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 2
Sep 24 11:19:45 bazzite kernel: nvidia 0000:01:00.0: vgaarb: deactivate vga console
Sep 24 11:19:45 bazzite kernel: fbcon: nvidia-drmdrmfb (fb0) is primary device
Sep 24 11:19:45 bazzite kernel: nvidia 0000:01:00.0: [drm] fb0: nvidia-drmdrmfb frame buffer device
Sep 24 11:19:47 bazzite kernel: BTRFS: device label bazzite-nvidia-open_hermes devid 1 transid 1198445 /dev/nvme1n1p3 (259:3) scanned by mount (933)
Sep 24 09:19:48 hermes systemd[1]: Listening on systemd-factory-reset.socket - Factory Reset Management.
Sep 24 09:19:48 hermes systemd[1]: modprobe@drm.service - Load Kernel Module drm skipped, unmet condition check ConditionKernelModuleLoaded=!drm
Sep 24 09:19:49 hermes kernel: zram0: detected capacity change from 0 to 33554432
Sep 24 09:19:49 hermes kernel: usbcore: registered new interface driver cdc_acm
Sep 24 09:19:49 hermes kernel: input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card0/input14
Sep 24 09:19:49 hermes kernel: input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card0/input15
Sep 24 09:19:49 hermes kernel: input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card0/input16
Sep 24 09:19:49 hermes kernel: input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card0/input17
Sep 24 09:19:49 hermes kernel: usbcore: registered new interface driver btusb
Sep 24 09:19:54 hermes kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
Sep 24 09:19:55 hermes kernel: evdi: [I] Initialising logging on level 4
Sep 24 09:19:55 hermes kernel: evdi: [I] Atomic driver: yes
may cause the guest operating system to hang or produce errors. If a guest
Sep 24 09:20:01 hermes kernel: [drm] [nvidia-drm] Infoframe changed on CRTC 0 (hdr=1 colorspace=1 vsif=0), adding planes on CRTC to atomic commit
Sep 24 09:20:01 hermes kernel: [drm] [nvidia-drm] Infoframe changed on CRTC 0 (hdr=1 colorspace=1 vsif=0), adding planes on CRTC to atomic commit
Sep 24 09:20:01 hermes kernel: [drm] [nvidia-drm] Infoframe changed on CRTC 0 (hdr=1 colorspace=1 vsif=0), adding planes on CRTC to atomic commit

===== KWIN LOG (last 10 min) =====
Sep 24 09:22:02 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:22:02 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:24:56 hermes kwin_wayland[3173]: “com.github.IsmaelMartinez.teams_for_linux” Stream error: no more input formats
Sep 24 09:24:56 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:26:28 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:26:28 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:26:28 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:26:28 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:26:29 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:26:29 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats
Sep 24 09:26:29 hermes kwin_wayland[3173]: “org.mozilla.firefox” Stream error: no more input formats
Sep 24 09:26:29 hermes kwin_wayland[3173]: PipeWire remote error: no more input formats

===== GPU / DRIVER =====
01:00.0 VGA compatible controller: NVIDIA Corporation AD104 [GeForce RTX 4070 Ti] (rev a1)
11:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c1)
nvidia_uvm
nvidia_drm
nvidia_modeset
nvidia
amdgpu
amdxcp
drm_panel_backlight_quirks
gpu_sched
drm_ttm_helper
drm_exec
drm_suballoc_helper
i915
drm_buddy
ttm
video
i2c_algo_bit
drm_display_helper
cec

11

This seems to be solved in 617.14. When will this be ready for Linux?

Ref: Reddit

Fixed General Bugs

  • FIXED No picture on Samsung Odyssey G95NC monitor when connected via HDMI after updating to R615 drivers [6771206]

  • FIXED Certain monitors may not wake from sleep when connected via DisplayPort after updating to R615 drivers [6757568]