Component swizzling during output, and synchronous output

Component swizzling during output, and synchronous output

[Simon.Richter]

Hi,

I have a video mixing desk which can accept a second input as a key 
source, translating luminance to opacity.

The obvious way to generate this is to build a compositor that provides 
an RGBA render target to applications, and then copies that to two output 
framebuffers.

Can I somehow skip that extra step and configure the RAMDACs to read the 
RGBA framebuffer directly (sending .rgb to one output, and .aaa to the 
other)?

Also, is there a way to synchronise two outputs that have the same 
resolution, so that the delay inside the mixing desk is the same?

   Simon

Re: Component swizzling during output, and synchronous output

[Ville Syrjälä]

On Tue, Nov 03, 2026 at 03:53:59AM +0900, Simon.Richter@hogyros.de wrote:
> Hi,
> 
> I have a video mixing desk which can accept a second input as a key 
> source, translating luminance to opacity.
> 
> The obvious way to generate this is to build a compositor that provides 
> an RGBA render target to applications, and then copies that to two output 
> framebuffers.
> 
> Can I somehow skip that extra step and configure the RAMDACs to read the 
> RGBA framebuffer directly (sending .rgb to one output, and .aaa to the 
> other)?

Reading from the same piece of memory on each output is easy.
Just point the planes on each at the same memory.

The swizzle is harder. Apart from blending the display hardware
just ignores the alpha channel. So you can't get at it so easily.
The obvious solution would be to treat the same ARGB fb as
RGBA for the other plane and then get the alpha channel out
as the red channel. Unfortunately I don't think our hardware
supports any swizzle with alpha at the bottom, it's always
at the top.

I guess one crazy idea would be to interpret the ARGB8888 data
as ARGB2101010 on the other plane. That way you could get the
six lsbs of the 8bit alpha into the red channel msbs. The top two
alpha bits would be out of reach, so whatever is producing the
data would have to deal with that. Then you use the pipe CSC to
replicate the red channel into blue/green. At that point you 
still have the problem of the four lsbs of each channel now
containing garbage from the actual 8bit red channel. But those
could be eradicated using the gamma LUT.

> 
> Also, is there a way to synchronise two outputs that have the same 
> resolution, so that the delay inside the mixing desk is the same?

On some platforms we have a hardware mechanism called port sync
for that. But it only works on DP outputs. And for now we've
only implemented it for SST. MST is theoretically possible but
no one has attempted to reshuffle the modeset code to get it
working.

Port sync is being replaced with something else in the new
hardware, which I think should work on HDMI as well. But I'm
not sure anyone has actually taken a look at what it would
take.

That said, I think getting the outputs almost into sync should
be possible without the hardware support as well. Would need to
figure out exactly when the timing generators start (which
incidentally I've just done) and then try to start them all
in one rapid burst. So (like the MST port sync case) it should
be a "small" matter of reshuffling the modeset sequence into
shape.

-- 
Ville Syrjälä
Intel