[PATCH] RFCv2: video support for dri2 (Rob Clark)

[Michal Suchanek]

2011/9/2 Rob Clark <rob.clark at linaro.org>:
> 2011/9/2 Christian König <deathsimple at vodafone.de>:
>> Hi Rob,
>>
>>>  + flipping between multiple back buffers, perhaps not in order (to
>>>    handle video formats with B-frames)
>> Oh, yes please. The closed source drivers seems to do this also all the
>> time, and I never really understood why DRI is limiting the buffers to
>> the OGL attachment points.

I guess you will also want to talk with mplayer folks about this. I'm
quite sure they will be one the first to exploit any new video
rendering interface.


>> ...
>>
>>> Current solutions use the GPU to do a scaled/colorconvert into a DRI2
>>> buffer from the client context.  The goal of this protocol change is
>>> to push the decision to use overlay or GPU blit to the xorg driver.
>> You left one corner case out, HDMI allows for the framebuffer to be in
>> YUV 4:4:4 format. So it is possible to send YUV data to the display
>> (usually a TV) without color conversion at all, but I think with the
>> current state of X we are years away from that.
>
> heh, yeah..
>
> possibly w/ overlays, at least when fullscreen and gfx layer is not
> visible, we could send YUV direct to the TV.. but I'm not really sure
> the practicality of switching back and forth between RGB and YUV

I'm not sure that's so much out of reach. IIRC there is some
foundation for non-RGB visuals in Mesa and on X server side there is
push to make the screens use separate buffers rather than one huge
'desktop' buffer with the ability to exchange these buffers on the fly
as needed.

Thanks

Michal