https://bugs.kde.org/show_bug.cgi?id=525308
Bug ID: 525308
Summary: Screencast plugin never emits SPA_META_VideoTransform,
so a flipped/rotated virtual output has zero signal
for consumers
Classification: Plasma
Product: kwin
Version First 6.3.6
Reported In:
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: screencasting
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
KWin's screencast plugin (src/plugins/screencast/screencaststream.cpp)
negotiates exactly three metadata types on its PipeWire stream:
SPA_META_Cursor, SPA_META_VideoDamage, and SPA_META_Header (plus
SPA_META_SyncTimeline when DMA-BUF sync objects are supported) -- see the
ParamMeta negotiation block at lines 199-214 of current master.
SPA_META_VideoTransform (added to PipeWire in 0.3.62, spa/meta.h) is never
registered or written to any buffer anywhere in this file, or anywhere else in
KWin's screencast implementation that I could find.
The practical effect: a screencast consumer using a portal-created
virtual/headless output has no way to learn that the compositor delivered a
transformed (rotated or flipped) buffer. It either has to assume the identity
transform and get a wrong picture, or infer orientation itself.
OBSERVED IMPACT
On a KDE Plasma 6.3.6 host (Debian 13) running lamco-rdp-server against a
dedicated/virtual-output screencast session (our primary use case:
headless/dedicated remote desktops, not sharing an in-use physical screen), the
delivered video was vertically flipped and mirrored end to end -- confirmed
correct only after manually forcing a client-side transform override equivalent
to PipeWire's Flipped180 value. Nothing in the PipeWire stream signaled this:
no SPA_META_VideoTransform, and the buffer's stride was reported as
positive/normal, so even the bottom-up/negative-stride heuristic some consumers
fall back on doesn't catch it either.
We've since implemented client-side empirical self-calibration (warp the
pointer, diff two captured frames, solve for the transform) to work around
compositors that give no metadata signal here, so this isn't blocking us -- but
it shouldn't be necessary. xdg-desktop-portal-wlr already emits
SPA_META_VideoTransform per buffer (its pipewire_screencast.c writes
spa_meta_videotransform from cast->current_frame.transformation), so there's
working precedent for the exact metadata KWin's screencast is missing.
REQUEST
Register SPA_META_VideoTransform as a supported ParamMeta type in
ScreenCastStream (alongside Cursor/VideoDamage/Header) and populate it on any
buffer whose orientation differs from the identity transform, matching
PipeWire's existing enum
(None/90/180/270/Flipped/Flipped90/Flipped180/Flipped270 -- semantically
identical to wl_output's transform enum). Happy to test against a build with
this if one exists in review.
--
You are receiving this mail because:
You are watching all bug changes.
