RFC: video with DRI2

[Rob Clark]

All,

I've been looking a bit at dri2 as a way to handle video display (in
addition to just GL stuff).  Basically it seems like a convenient way
to share buffer handles between Xorg driver and client video player
app.  (Yes, I know about Xv.. no, it isn't useful if I want to avoid a
memcpy.)

The basic differences compared to some 3d/gl app:
1) color format..  video content would (most likely) be in some YUV
format.  No problem for DRI2GetBuffersWithFormat, passing a fourcc as
the 'format' value seems sane.

2) attachment points.. for GL you might triple or double buffer.  For
video you might have >16 buffers.  This mostly seems ok, most of the
existing dri2.c code seems like it would tolerate me requesting
non-existing attachment points.  The one bit of awkwardness is that
DRI2SwapBuffers doesn't let me specify *which* buffers I want to swap.
 Maybe I could cope by playing some games by changing buffer name to
buffer object mappings.  The tricky thing to keep in mind is that in
the video case the buffers would be displayed in a seemingly random
(to the xorg driver) order, if B-frames are present..  decode order !=
display order

3) cropping.. in case you are actually trying to share buffers without
copy between video codec and Xorg, you probably have some codec edges
that need to be cropped out.  So you need some way to request buffers
larger than the target drawable, and specify some x,y offset into that
larger buffer to find what should appear on screen.  In some cases it
might even be that the x,y offset is changing frame by frame.


Some of these issues go away if you do a blit/colorconvert on client
side into the DRI2 buffer.  This seems to be what intel vaapi driver
(and probably others) are doing currently.  Although my ideal goal is
to push this to xorg side, and let xorg driver decide whether to blit,
or use an overlay, etc.


The approaches I can think of to deal with this are:
1) add DRI2Get/SetProperty sort of messages.  Some things like
cropping offsets and perhaps actual requested buffers sizes could be
set as properties.  There are some things that are a bit iff'y about
this.  For example, changing crop should apply on the next
SwapBuffers.  The good news is it would be easy to later define new
properties as the need arises.

2) Add additional parameters to GetBuffers and SwapBuffers

3) Define some new msgs with extra parameters...
DRI2GetBufferWithFormatAndMore, etc.


Anyone have some opinions on the best approach to take?  Anyone else
given some thought to this sort of thing before?



BR,
-R