| @@ -1,98 +1,18 @@
-From 5e832833f9382b84b29d87e6d4ac2ec19040ea4d Mon Sep 17 00:00:00 2001
-From: Rob Clark <rob@ti.com>
-Date: Tue, 15 Nov 2011 13:50:41 -0600
-Subject: [PATCH 2/2] video support for dri2
-
-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.
-
-In many cases, an overlay will avoid several passes through memory
-(blit/scale/colorconvert to DRI back-buffer on client side, blit to
-front and fake-front, and then whatever compositing is done by the
-window manager). On the other hand, overlays can often be handled
-directly by the scanout engine in the display hardware, with the GPU
-switched off.
-
-The disadvantages of overlays are that they are (usually) a limited
-resource, sometimes with scaling constraints, and certainly with
-limitations about transformational effects.
-
-The goal of combining video and dri2 is to have the best of both worlds,
-to have the flexibility of GPU blitting (ie. no limited number of video
-ports, no constraint about transformational effects), while still having
-the power consumption benefits of overlays (reduced memory bandwidth
-usage and ability to shut off the GPU) when the UI is relatively
-static other than the playing video.
-
-And even when GPU blitting is used, DRI2DriverXV allows to save one or
-two copies: (1) no need for maintainence of DRI2BufferFakeFrontLeft, and
-(2) in case that a pointer swap is not possible for switching back and
-front buffer (for example, Window redirected to a pixmap with extra
-padding around edges for window decorations), the colorconvert/scale
-blit can be combined with the copy to the front buffer.
-
-See:
-https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=get&target=linux-video.pdf
-
-ChangeLog:
-v1: initial version
-v2: add attributes, remove DRI2GetVideoBuffers/DRI2ATTACH_VIDEO and
- instead use attributes to specify unscaled width/height
-v3: support for variable length attributes and CSC matrix
-v4: add header file changes
-
-Note: I'm not entirely sure how to handle the wire representation of
-float matrix for CSC. OTOH, since DRI2 is a local-only protocol, I'm
-not sure if it is necessary to precisely define this. Thoughts?
----
- dri2proto.h | 91 +++++++++++++++++++-
- dri2proto.txt | 275 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
- dri2tokens.h | 1 +
- 3 files changed, 362 insertions(+), 5 deletions(-)
-
-diff --git a/dri2proto.h b/dri2proto.h
-index cd82afb..5d25da5 100644
---- a/dri2proto.h
-+++ b/dri2proto.h
-@@ -35,7 +35,7 @@
-
- #define DRI2_NAME "DRI2"
- #define DRI2_MAJOR 1
--#define DRI2_MINOR 3
-+#define DRI2_MINOR 4
-
- #define DRI2NumberErrors 0
- #define DRI2NumberEvents 2
-@@ -54,6 +54,11 @@
- #define X_DRI2WaitMSC 10
+--- a/dri2proto.h 2012-07-06 14:38:43.000000000 +0100
++++ b/dri2proto.h 2013-04-22 17:39:31.461811521 +0100
+@@ -55,6 +55,11 @@
#define X_DRI2WaitSBC 11
#define X_DRI2SwapInterval 12
-+#define X_DRI2GetBuffersVid 13
-+#define X_DRI2SwapBuffersVid 14
-+#define X_DRI2SetAttribute 15
-+#define X_DRI2GetAttribute 16
-+#define X_DRI2GetFormats 17
+ #define X_DRI2GetParam 13
++#define X_DRI2GetBuffersVid 14
++#define X_DRI2SwapBuffersVid 15
++#define X_DRI2SetAttribute 16
++#define X_DRI2GetAttribute 17
++#define X_DRI2GetFormats 18
/*
* Events
-@@ -164,6 +169,17 @@ typedef struct {
+@@ -165,6 +170,17 @@
#define sz_xDRI2GetBuffersReq 12
typedef struct {
@@ -110,7 +30,7 @@
BYTE type; /* X_Reply */
BYTE pad1;
CARD16 sequenceNumber B16;
-@@ -217,6 +233,25 @@ typedef struct {
+@@ -218,6 +234,25 @@
#define sz_xDRI2SwapBuffersReq 32
typedef struct {
@@ -136,8 +56,8 @@
BYTE type; /* X_Reply */
BYTE pad1;
CARD16 sequenceNumber B16;
-@@ -286,6 +321,60 @@ typedef struct {
- #define sz_xDRI2SwapIntervalReq 12
+@@ -318,6 +353,60 @@
+ #define sz_xDRI2BufferSwapComplete2 32
typedef struct {
+ CARD8 reqType;
@@ -197,381 +117,9 @@
CARD8 type;
CARD8 pad;
CARD16 sequenceNumber B16;
-diff --git a/dri2proto.txt b/dri2proto.txt
-index dea8b82..987b772 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,11 @@ 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. There is no
-+ automatic maintenance of DRI2BufferFakeFrontLeft.
-+
- DRI2BUFFER { attachment: CARD32
- name: CARD32
- pitch: CARD32
-@@ -193,7 +199,7 @@ DRI2BUFFER { attachment: CARD32
- The DRI2BUFFER describes an auxillary rendering buffer
- associated with an X drawable. 'attachment' describes the
- attachment point for the buffer, 'name' is the name of the
-- underlying kernel buffer,
-+ underlying kernel buffer.
-
-
- DRI2ATTACH_FORMAT { attachment: CARD32
-@@ -201,7 +207,8 @@ DRI2ATTACH_FORMAT { attachment: CARD32
-
- The DRI2ATTACH_FORMAT describes an attachment and the associated
- format. 'attachment' describes the attachment point for the buffer,
-- 'format' describes an opaque, device-dependent format for the buffer.
-+ 'format' describes an opaque, device-dependent format for the buffer,
-+ or a fourcc for non-device-dependent formats.
-
- ⚙ ⚙ ⚙ ⚙ ⚙ ⚙
-
-@@ -327,6 +334,9 @@ The name of this extension is "DRI2".
- ┌───
- DRI2SwapBuffers
- drawable: DRAWABLE
-+ target_msc: two CARD32s
-+ divisor: two CARD32s
-+ remainder: two CARD32s
- ▶
- count: two CARD32s
- └───
-@@ -342,6 +352,31 @@ The name of this extension is "DRI2".
- later.
-
- ┌───
-+ DRI2SwapBuffersVid
-+ drawable: DRAWABLE
-+ target_msc: two CARD32s
-+ divisor: two CARD32s
-+ remainder: two CARD32s
-+ source: CARD32
-+ x1: CARD32
-+ y1: CARD32
|
