Bug 518008 - Spectacle/KPipeWire on hybrid AMD+NVIDIA systems can select the wrong recording device, crashing MP4/H.264 and producing invalid WebM/VP9 files
Summary: Spectacle/KPipeWire on hybrid AMD+NVIDIA systems can select the wrong recordi...
Status: RESOLVED FIXED
Alias: None
Product: KPipeWire
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 6.6.3
Platform: NixOS Linux
: NOR crash
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-03-22 18:42 UTC by marshland3943
Modified: 2026-03-26 17:23 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.7.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description marshland3943 2026-03-22 18:42:13 UTC
SUMMARY
On my hybrid AMD+NVIDIA laptop, Spectacle/KPipeWire recording on Wayland could choose the wrong GPU/render device for the recording pipeline.

Before a local fix, KPipeWire selected AMD VAAPI on /dev/dri/renderD129 even though the active session/compositor was on NVIDIA. In that state:
- MP4/H.264 recording crashed Spectacle
- WebM/VP9 recording produced an invalid/corrupt file

This appears to be caused by KPipeWire inferring GPU/render devices independently in multiple places instead of resolving the current session render node once and using it consistently.

STEPS TO REPRODUCE
1. Use a hybrid AMD+NVIDIA laptop on Plasma Wayland, where the compositor/session is running on the NVIDIA dGPU and multiple render nodes exist.
2. Start a screen recording in Spectacle.
3. Record with MP4/H.264 or WebM/VP9 and stop the recording.

OBSERVED RESULT
KPipeWire selected AMD VAAPI for recording on this hybrid system:
kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 26.0.2 for AMD Radeon Graphics (radeonsi, renoir, ACO, DRM 3.64, 6.19.8) in use for device "/dev/dri/renderD129"

With MP4/H.264, Spectacle crashed. Relevant stack frames:
Program terminated with signal SIGSEGV, Segmentation fault.
#4  ff_hw_base_encode_receive_packet
#6  avcodec_send_frame
#7  Encoder::finish() from libKPipeWireRecord.so.6
#8  PipeWireProduce::stateChanged(pw_stream_state) from libKPipeWireRecord.so.6

With WebM/VP9, the output file was invalid/corrupt. Relevant errors:
[matroska,webm @ ...] Duplicate element
[matroska,webm @ ...] 0x00 at pos 100 (0x64) invalid as first byte of an EBML number
[matroska,webm @ ...] Duplicate element
[matroska,webm @ ...] 0x00 at pos 167 (0xa7) invalid as first byte of an EBML number
[matroska,webm @ ...] Element at 0x5d ending at 0x1aec0100000066 exceeds containing master element ending at 0x1409
qt.multimedia.ffmpeg.mediadataholder: Could not open media. FFmpeg error description: End of file

EXPECTED RESULT
KPipeWire should resolve the current session render node once and use that same GPU consistently for:
- VAAPI device selection
- DMA-BUF import
- stream modifier negotiation
Recording should not crash for MP4/H.264 and should not produce invalid WebM/VP9 files.

SOFTWARE/OS VERSIONS
Operating System: NixOS Unstable channel
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
Kernel Version: 6.19.8 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 4600H with Radeon Graphics
Memory: 40 GiB of RAM (38.6 GiB usable)
Graphics Processor 1: NVIDIA GeForce GTX 1650
Graphics Processor 2: AMD Radeon Graphics

ADDITIONAL INFORMATION
I tested a local fix that introduces a shared session render-node resolver and uses it consistently across:
- vaapiutils.cpp
- dmabufhandler.cpp
- pipewiresourcestream.cpp
With that patch:
- the recording pipeline uses the session render node instead of a foreign GPU
- MP4/H.264 no longer crashes
- WebM/VP9 produces a valid file

The patch will be in the MR
Comment 1 Bug Janitor Service 2026-03-22 19:16:28 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/239
Comment 2 Nate Graham 2026-03-26 17:23:18 UTC
Git commit 76f05c8ccfb6586d068d0f57c3b6554658865e54 by Nate Graham, on behalf of Marsh Land.
Committed on 26/03/2026 at 17:23.
Pushed by ngraham into branch 'master'.

recording: Use the current session render node consistently across recording

KPipeWire currently chooses GPU/render devices in multiple places independently
(VAAPI selection, DMA-BUF handling, modifier negotiation). On hybrid systems
this can lead to inconsistent GPU selection across the recording pipeline.

This change introduces a shared session render-node resolver and uses the
current session render node consistently for:

- VAAPI device selection
- DMA-BUF import path
- stream modifier negotiation
FIXED-IN: 6.7.0

M  +2    -0    autotests/CMakeLists.txt
M  +2    -1    src/CMakeLists.txt
M  +8    -36   src/dmabufhandler.cpp
M  +16   -4    src/pipewiresourcestream.cpp
A  +92   -0    src/rendernodecontext.cpp  *
A  +28   -0    src/rendernodecontext_p.h  *
M  +17   -28   src/vaapiutils.cpp

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/plasma/kpipewire/-/commit/76f05c8ccfb6586d068d0f57c3b6554658865e54