https://bugs.kde.org/show_bug.cgi?id=522735
--- Comment #9 from [email protected] --- (In reply to bvppel1x from comment #7) > (In reply to Zamundaaa from comment #5) > > The problem seems to be that KWin can't get a functioning framebuffer: > > > GL_INVALID_OPERATION error generated. <image> and <target> are > > > incompatible > > > > Do you have any environment variables set that are related to KWin? > > > > Also, does either one of these make a difference? > > > KWIN_DRM_DEVICES=/dev/dri/card2 > > > KWIN_DISABLE_VULKAN=1 > > No, I don't have any KWin-related environment variables set. That report and > the earlier clean log were on a stock session with nothing overridden, and I > double-checked there's no systemd drop-in or anything setting KWIN_* for the > compositor. > > > I tried KWIN_DISABLE_VULKAN=1 on its own and it makes no difference. The > session still comes up with no signal on the monitor (which is the only > display, plugged into the NVIDIA), degrades to a placeholder screen, and the > journal has the same GL_INVALID_OPERATION "<image> and <target> are > incompatible" plus GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT flood as before, > this time about 288 of them across several output reconfigs. I'm attaching > that boot's plasma-kwin_wayland log. > > I also tried KWIN_DRM_DEVICES pointed at the NVIDIA and it made no > difference either, same errors and no image. One thing worth flagging: the > DRM card numbering isn't stable between boots on this machine, the NVIDIA > has come up as both card0 and card2 on different boots, so /dev/dri/card2 > isn't reliably the NVIDIA here. To be sure I was pinning the right node I > used a udev symlink tied to the NVIDIA's PCI address (0000:01:00.0) instead > of a literal cardN, and it still failed the same way One more thing that might be the useful part. I noticed you just added the KWIN_RENDER_NODES variable (commit 61aae2174ceb). My case is a bit different from the VFIO/power reports linked here: my monitor is the only display and it's plugged into the NVIDIA, but KWin ends up rendering on the AMD iGPU, and it's the cross-GPU copy to the NVIDIA that fails (the GL_INVALID_OPERATION flood), so I get no image at all rather than just an idle dGPU holding an fd. Would restricting KWin to the NVIDIA render node (renderD129 on this box) with KWIN_RENDER_NODES force it to render on the same GPU the monitor is on and skip that copy path entirely? If that's the right idea, would you consider backporting the variable to the Plasma 6.7 branch? In this desktop no-signal case there's no fallback screen at all, so it's basically an unusable machine until 6.8, unlike the reports where the desktop stays usable. I saw it went into master; I'll test it the moment it's in a build I can install either way. -- You are receiving this mail because: You are watching all bug changes.
