https://bugs.kde.org/show_bug.cgi?id=512511
--- Comment #7 from Zamundaaa <[email protected]> --- (In reply to Nikola Novoselec from comment #6) > When KWin tries to wake it up, it appears to just flip CRTC.ACTIVE from 0 to > 1 via DrmPipeline::commitPipelines() and submits an atomic commit without > DRM_MODE_ATOMIC_ALLOW_MODESET. KWin actually always severs connection between connector and crtc completely, and always allows a full modeset on dpms changes. It just has the optimization that, if the driver doesn't actually require a modeset, we skip it. I'm surprised the Nvidia driver would ever allow such configuration changes without a modeset, but if you want to investigate that further, as I wrote before, make a new bug report. This one is not about a Nvidia driver bug. > The -EPERM from nvidia-drm is their way of saying "I can't do this without a > modeset". Standard DRM usually returns -EINVAL for bad configs, but NVIDIA > uses -EPERM when resource allocation fails or the hardware state requires a > full modeset to proceed. As I mentioned before, "permission denied" errors are from the VT switch, there's nothing more to it. > VT switch forces drmDropMaster()/drmSetMaster(). KWin re-acquires master, > treats the GPU as "new", and does full initialization including link > training. This proves the hardware and driver can wake correctly - it's just > the atomic fast-path that's broken for DSC. KWin doesn't really do anything special on VT switches with atomic modesetting (legacy does force a modeset, because of bugs in old and not super well maintained drivers). If I had to guess, I'd say the VT switch changes some driver-internal state, and maybe forces a modeset on the driver side. > This is significant: Even during the failure state, the driver reports > everything as healthy. It silently fails the atomic commit with -EPERM while > claiming the link is fine. If drm_info shows the screen is on while it's actually not receiving any signal, then that is definitely a driver bug. You can report it at https://github.com/NVIDIA/open-gpu-kernel-modules/issues. > Other Compositors > I'm not the only one hitting this - wlroots, Hyprland and Sway are all adding > the same workaround: > swaywm/wlroots#2373 > hyprwm/Hyprland#2696 Neither of theses issues are related to what you describe, and don't hint at wlroots or Hyprland doing any such workaround either... > Future optimization: Could theoretically be made conditional on: > - The upcoming kernel flag DRM_MODE_FLAG_DSC There's no such flag to be found on dri-devel or Google. Did you use an LLM to hallucinate this research? -- You are receiving this mail because: You are watching all bug changes.
