[PATCH dri2proto] RFC: video support for dri2

Rob Clark robdclark at gmail.com
Thu Aug 18 19:58:07 PDT 2011

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
-	     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
+	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".
+    DRI2GetVideoBuffers
+	drawable: DRAWABLE
+	attachments: LISTofDRI2ATTACH_VIDEO
+      ▶
+	width, height: CARD32
+	buffers: LISTofDRI2BUFFER
 	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.
 	4	CARD32	attachment
@@ -599,6 +633,17 @@ A.1 Common Types
 	This data type is only available with protocol version 1.1 or
+	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.

More information about the xorg-devel mailing list