Bug 495287 - PipeWire Screen Capture Freezes Fullscreen Target Applications
Summary: PipeWire Screen Capture Freezes Fullscreen Target Applications
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: screencasting (show other bugs)
Version: 6.2.5
Platform: Arch Linux Other
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 499776 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-10-24 08:38 UTC by dream
Modified: 2025-02-10 20:43 UTC (History)
11 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/kwin/-/commit/45a5d8844b36404334301f5da6e75f1a345e0c80
Version Fixed In: 6.3.0
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description dream 2024-10-24 08:38:49 UTC 
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.
Comment 1 Oleh 2024-10-26 09:39:32 UTC 
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
Comment 2 WheatMcGrass 2024-10-29 01:10:17 UTC 
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
Comment 3 dream 2024-11-07 00:05:06 UTC 
Confirmed issue persists on kwin 6.2.3.
Comment 4 Jonah Jones 2024-12-16 01:29:45 UTC 
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
Comment 5 dream 2024-12-22 21:08:59 UTC 
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.
Comment 6 dream 2025-01-04 05:30:48 UTC 
Reproduced in 6.2.5-2
Comment 7 ttthwvezrjdmeldtud 2025-01-07 01:35:44 UTC 
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
Comment 8 light.bed3900 2025-01-08 23:58:03 UTC 
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
Comment 9 Bug Janitor Service 2025-01-09 18:48:38 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6980
Comment 10 Zamundaaa 2025-01-10 13:43:30 UTC 
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
Comment 11 Zamundaaa 2025-01-10 17:38:05 UTC 
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
Comment 12 Zamundaaa 2025-02-10 20:43:21 UTC 
*** Bug 499776 has been marked as a duplicate of this bug. ***