SUMMARY Performing a PipeWire screen capture that invokes Portal is freezing the targeted Window if a Window is selected rather than the whole screen, but only for devices with two GPUs where the secondary GPU is being used to render the target Window. kwin 6.1.2 does not have the issue. All newer versions experience this bug. STEPS TO REPRODUCE On a computer with two GPUs (such as a laptop) running Wayland (iGPU & dGPU) with "obs-studio" installed... 1. Launch any fullscreen application where the secondary GPU will be used (ex use prime-run). In my own tests, I use dolphin-emu, pick my dGPU in Graphics configuration, use Vulkan as backend, launch a process, then Alt+Enter to full screen the application. 2. Launch OBS Studio 3. Create a new source "Screen Capture (PipeWire)" 4. Open this source and select "Open Selector" 5. When Portal appears, select "Windows" and select your fullscreen application. 6. Immediately the target application should freeze/halt - no frames will be generated. Triggering focus/unfocus on the window with alt-tab will sometimes unfreeze the application. 7. Close OBS / stop the PipeWire capture - the application will unfreeze. OBSERVED RESULT An OBS PipeWire 'Windows' capture freezes target applications if on Wayland with dGPU on kwin 6.2.2 EXPECTED RESULT An OBS PipeWire 'Windows' capture properly can view the window, and the target application is not frozen. kwin 6.1.2 is the last version where this works as expected. SOFTWARE/OS VERSIONS Operating System: CachyOS Linux KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.6.57-2-cachyos-lts (64-bit) Graphics Platform: Wayland Processors: 32 × 13th Gen Intel® Core™ i9-13900HX Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Graphics (iGPU) & NVIDIA GeForce RTX 4080 (dGPU) ADDITIONAL INFORMATION I noticed another user reported the exact same issue on an unrelated forum. I did not see this reported on KDE bugtracker, which led me to opening this. https://forum.endeavouros.com/t/screen-freezing-in-fullscreen-apps-using-prime-run/61880 It is worth noting additionally similar weird behavior was observed on kwin versions 6.1.3-6.2.0 on a Desktop with one GPU. Though the freezing occurred if a target application would hide the mouse cursor. At one point the freezing was flipped to only occur if the mouse was shown, and not freeze when hidden. However I can not reproduce any such freezing for single GPU case as of 6.2.2.
I have exactly the same issue, but on PC with one GPU Additionally freezing does not occur if I do one of these: 1. Drag OBS Studio window (or other capture app) to the another monitor 2. Enable HDR or change color profile in KDE settings My setup: CPU - Ryzen 5600X GPU - Radeon 6800XT KDE Plasma version - 6.2.2
I can confirm that I can reproduce the same issue, though on a system with only one GPU. Occurs when capturing a window with OBS and with Vesktop. # Specs: Operating System: Fedora Linux 40 KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.11.4-201.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2
Confirmed issue persists on kwin 6.2.3.
I'm experiencing this issue also while trying to stream a game on discord or with obs. I can capture the full desktop or windowed applications fine, and the application is still responsive if I run it in gamescope. Let me know if there's any debug or additional info that'd be helpful to provide SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.4-zen Graphics Platform: Wayland Graphics: NVIDIA GeForce RTX 3080
Kwin version 6.2.4-4 still has the same problem too. I also notice on single GPU (my desktop) I am running into similar issues when capturing a Window directly if the app hides the mouse cursor. The target window will be frozen (not just in the recording- the actual application) while the Window is being captured and the mouse hides itself.
Reproduced in 6.2.5-2
Experiencing this bug too, specifically with VESKTOP (Flatpack). Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.7-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 7600 6-Core Processor Memory: 30.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4060/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B650M C V2-Y1 System Version: -CF
I'm also experiencing this on my single-GPU system. It seems to only occur when capturing a specific window via PipeWire - other methods of capture (e.g. PipeWire full screen capture, OBS Game Capture), function as expected. Operating System: Nobara Linux 41 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.7-200.fsync.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4090/PCIe/SSE2
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6980
Git commit b1031ea63eaa8c9bf5c70157d1b6bf8eb0f5a74a by Xaver Hugl. Committed on 10/01/2025 at 12:36. Pushed by zamundaaa into branch 'master'. plugins/screencast: call ItemRenderer::begin/endFrame The OpenGL renderer references the explicit sync release points for client buffers during rendering, and releases them in endFrame. If endFrame never gets called though (for example because we're doing direct scanout) then the release points never get signaled, and the client very quickly runs out of buffers to use and freezes. M +2 -2 src/plugins/screencast/windowscreencastsource.cpp https://invent.kde.org/plasma/kwin/-/commit/b1031ea63eaa8c9bf5c70157d1b6bf8eb0f5a74a
Git commit 45a5d8844b36404334301f5da6e75f1a345e0c80 by Xaver Hugl. Committed on 10/01/2025 at 13:45. Pushed by zamundaaa into branch 'Plasma/6.3'. plugins/screencast: call ItemRenderer::begin/endFrame The OpenGL renderer references the explicit sync release points for client buffers during rendering, and releases them in endFrame. If endFrame never gets called though (for example because we're doing direct scanout) then the release points never get signaled, and the client very quickly runs out of buffers to use and freezes. (cherry picked from commit b1031ea63eaa8c9bf5c70157d1b6bf8eb0f5a74a) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +2 -2 src/plugins/screencast/windowscreencastsource.cpp https://invent.kde.org/plasma/kwin/-/commit/45a5d8844b36404334301f5da6e75f1a345e0c80
*** Bug 499776 has been marked as a duplicate of this bug. ***