[PATCH dri2proto] RFC: video support for dri2

[Rob Clark]

From: Rob Clark <rob at ti.com>

To allow the potential use of overlays to display video content, a few
extra parameters are required:

 + source buffer in different format (for example, various YUV formats)
   and size as compared to destination drawable
 + multi-planar formats where discontiguous buffers are used for
   different planes.  For example, luma and chroma split across
   multiple memory banks or with different tiled formats.
 + flipping between multiple back buffers, perhaps not in order (to
   handle video formats with B-frames)
 + cropping during swap.. in case of video, perhaps the required hw
   buffers are larger than the visible picture to account for codec
   borders (for example, reference frames where a block/macroblock
   moves past the edge of the visible picture, but back again in
   subsequent frames).

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.
---
Eventually this should replace Xv.  With a few additions, like attributes,
it could perhaps be possible to implement the client side Xv API on top
of dri2.

Note: video is not exactly the same as 3d, there are a number of other
things to consider (scaling, colorconvert, multi-planar formats).  But
on the other hand the principle is similar (direct rendering from hw
video codecs).  And a lot infrastructure of connection, authentication,
is same.  So there are two options, either extend DRI2 or add a new
protocol which duplicates some parts.  I'd like to consider extending
DRI2 first, but if people think the requirements for video are too
much different from 3d, then I could split this into a new protocol.

In either case, I will implement the xserver side infrastructure, but
I wanted to get some feel for what is the preferred approach (extend
dri2 or new videoproto) first.

 dri2proto.txt |   60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..aa83b1a 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
 6. Protocol Types
 
 DRI2DRIVER { DRI2DriverDRI
-	     DRI2DriverVDPAU }
+	     DRI2DriverVDPAU,
+	     DRI2DriverXV }
 
 	These values describe the type of driver the client will want
 	to load.  The server sends back the name of the driver to use
@@ -184,6 +185,10 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
 	These values describe various attachment points for DRI2
 	buffers.
 
+	In the case of video driver (DRI2DriverXV) the attachment,
+	other than DRI2BufferFrontLeft, just indicates buffer
+	number and has no other special significance.
+
 DRI2BUFFER { attachment: CARD32
     	     name: CARD32
 	     pitch: CARD32
@@ -203,6 +208,16 @@ DRI2ATTACH_FORMAT { attachment: CARD32
 	format.  'attachment' describes the attachment point for the buffer,
 	'format' describes an opaque, device-dependent format for the buffer.
 
+
+DRI2ATTACH_VIDEO { attachment: CARD32
+		    format:     CARD32,
+		    width, height:	CARD32 }
+
+	The DRI2ATTACH_VIDEO describes an attachment and the associated
+	format for video buffers.  'attachment' describes the attachment
+	point for the buffer, 'format' describes a fourcc value for the
+	buffer.
+
 			     ⚙ ⚙ ⚙  ⚙ ⚙ ⚙
 
 
@@ -367,6 +382,15 @@ The name of this extension is "DRI2".
 	later.
 
 ┌───
+    DRI2GetVideoBuffers
+	drawable: DRAWABLE
+	attachments: LISTofDRI2ATTACH_VIDEO
+      ▶
+	width, height: CARD32
+	buffers: LISTofDRI2BUFFER
+└───
+
+┌───
     DRI2GetMSC
 	drawable: DRAWABLE
       ▶
@@ -585,11 +609,21 @@ A.1 Common Types
 	4	CARD32	pitch
 	4	CARD32	cpp
 	4	CARD32	flags
+	4	n	extra names length
+	4n	LISTof	extra names
 └───
 	A DRI2 buffer specifies the attachment, the kernel memory
 	manager name, the pitch and chars per pixel for a buffer
 	attached to a given drawable.
 
+	In case of multi-planar video formats, 'extra names' will give the
+	list of additional buffer names if there is one buffer per plane.
+	For example, I420 has one Y plane in with a 8bit luma value per
+	pixel, followed by one U plane subsampled 2x2 (with one 8bit U value
+	per 2x2 pixel block), followed by one V plane subsampled 2x2.  This
+	could either be represented as a single buffer name, or three
+	separate buffer names, one each for Y, U, and V.
+
 ┌───
     DRI2ATTACH_FORMAT
 	4	CARD32	attachment
@@ -599,6 +633,17 @@ A.1 Common Types
 	This data type is only available with protocol version 1.1 or
 	later.
 
+┌───
+    DRI2ATTACH_VIDEO
+	4	CARD32	attachment
+	4	CARD32	format
+	4	CARD32	width
+	4	CARD32	height
+└───
+	Used to describe the attachment and format requested from the server.
+	This data type is only available with protocol version 1.? or
+	later.
+
 A.2 Protocol Requests
 
 ┌───
@@ -745,6 +790,11 @@ A.2 Protocol Requests
 	4	CARD32			divisor_lo
 	4	CARD32			remainder_hi
 	4	CARD32			remainder_lo
+	4	DRI2ATTACHMENT		source
+	4	CARD32			x1
+	4	CARD32			y1
+	4	CARD32			x2
+	4	CARD32			y2
       ▶	
 	1	1			Reply
         1				unused
@@ -754,6 +804,14 @@ A.2 Protocol Requests
 	4	CARD32			swap_lo
 	5n	LISTofDRI2BUFFER	buffers
 └───
+	The 'source', if not zero (DRI2BufferFrontLeft) indicates the
+	attachment point of the buffer to swap w/ DRI2BufferFrontLeft.
+	If zero is specified, DRI2BufferBackLeft is swapped with the
+	DRI2BufferFrontLeft buffer, for compatibility.
+
+	If 'source' is not zero, (x1,y1), (x2,y2) specify the bounding
+	box in coordinates of the source buffer which should be scaled
+	to (0,0), (width,height) of the destination drawable.
 
 ┌───
     DRI2GetMSC
-- 
1.7.5.4