Hi,

Keith talked me intro writing a spec for DRI2, which I grudgingly must
admit is a good idea.  I used the randr spec as a template, except I
replaced the flowery section dividers with a more fitting gears motif.
 It's still a work in progress, mostly the introductory/background
sections though.  The requests and wire encoding sections are mostly
complete and is close to what's in the git repos at this point.  The
implementation isn't fully uptodate with the spec yet, but I figured
it would be wise to circulate the spec before doing more code churn,
so here it is.

cheers,
Kristian
                          The DRI2 Extension
                              Version 2.0
                              2008-09-04
      
                          Kristian Høgsberg
                            [EMAIL PROTECTED]
                             Red Hat, Inc


1. Introduction

DRI2 blurb


1.1 Acknowledgements

kem, keithp, anholt, keithw, glisse, idr


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


2. DRI2 Concepts

The DRI2 extension is designed to associate and access auxillary
buffers with an X drawable.

DRI2 is a essentially a helper extension to support implementation of
direct rendering drivers/libraries/technologies.

Relation to XF86DRI

Attachment points

Assumes an underlying kernel video memory manager that can provide 32
bit integer handles to buffers, that can be passed between processes.

No ordering between swap buffers and X rendering.  X rendering to src
buffers will block if they have a vblank pending.

Relies on DRM, not memory manager specific, but designed to work with GEM.

Authentication model.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙

                                   
3. Data Types

The subpixel order is shared with the Render extension, and is documented
there. The only datatype defined is the screen size, defined in the normal
(0 degree) orientation.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


4. Errors

Errors are sent using core X error reports.

Authenticate
        The X server failed to authenticate the client.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


5. Protocol Types

DRI2ATTACHMENT { DRI2_BUFFER_FRONT_LEFT
                 DRI2_BUFFER_BACK_LEFT
                 DRI2_BUFFER_FRONT_RIGHT
                 DRI2_BUFFER_BACK_RIGHT
                 DRI2_BUFFER_DEPTH
                 DRI2_BUFFER_STENCIL
                 DRI2_BUFFER_ACCUM
                 DRI2_BUFFER_FAKE_FRONT_LEFT
                 DRI2_BUFFER_FAKE_FRONT_RIGHT }

        These values describe various attachment points for DRI2
        buffers.

DRI2BUFFER { attachment: CARD32
             name: CARD32
             pitch: CARD32
             cpp: CARD32
             flags: CARD32 }


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


6. Extension Initialization

The name of this extension is "DRI2".

┌───
    DRI2QueryVersion
        client-major-version:   CARD32
        client-minor-version:   CARD32
      ▶
        major-version:          CARD32
        minor-version:          CARD32
└───

        The client sends the highest supported version to the server
        and the server sends the highest version it supports, but no
        higher than the requested version. Major versions changes can
        introduce incompatibilities in existing functionality, minor
        version changes introduce only backward compatible changes.
        It is the clients responsibility to ensure that the server
        supports a version which is compatible with its expectations.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


7. Extension Requests

┌───
    DRI2Connect
        window: WINDOW
        type: STRING
      ▶
        driver: STRING
        device: STRING  -- device file name
        group: CARD32
└───

        Returns the driver name and device file to use for the
        specified driver type for the screen associated with 'window'.

        'type' identifies the type of driver to query for.

        'driver' is the name of the driver to load.  The client is
        assumed to know where to look for the drivers and what to do
        with it.

        'device' is the filename of the drm device file.

        'group' is the authentication group the server uses.

        If the client is not local, or the request driver type is
        unknown or not available, 'driver' and 'device' will be empty
        strings, 'group' will be '0'.  We are not using an regular X
        error here to indicate failure, which will allow the client
        fall back to other options more easily.

        Implementation notes: For the GEM memory manager, use the
        GEM_INVITE ioctl to create a token for requesting access to
        the servers authentication group.
        
┌───
    DRI2Authenticate
        window: WINDOW
        token: CARD32
└───
        Errors: Window, Authenticate

        Request that the X server authenticates 'token', allowing the
        client to access the drm buffers created by the X server on
        the screen associated with 'window'.

        Authentication shouldn't fail at this point, except if an
        invalid token is passed, in which case an Authenticate error
        is generated.

┌───
    DRI2GetBuffers
        drawable: DRAWABLE
        attachments: LISTofDRI2ATTACHMENTS
      ▶       
        width, height: CARD32
        buffers: LISTofDRI2BUFFER
└───
        Errors: Window

        Get buffers for the provided attachment points for the given
        drawable.

        If the DDX driver does not support one or more of the
        specified attachment points, a Value error is generated, with
        the first unsupported attachment point as the error value.

        'width' and 'height' describes the dimensions of the drawable.

        'buffers' 

        ISSUES: Do we need the position of the window as well so that 

┌───
    DRI2CopyRegion
        drawable: DRAWABLE
        region: REGION
        source: DRI2ATTACHMENT
        destination: DRI2ATTACHMENT
        flags: CARD32
        sequence: CARD32
└───
        Errors: Window

        Returns the range of possible screen sizes. The screen may be set to
        any size within this range.

        'flags' VSYNC: perform copy at the start of the vertical
        retrace specified by sequence, COPY: keep src contents, for
        copy region and , otherwise unspecified, which allows
        glXSwapBuffer to do pageflip.

        sequence: the vblank sequence number where the swap should be
        scheduled, if the VSYNC flag is set.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


8. Extension Versioning

The RandR extension was developed in parallel with the implementation
to ensure the feasibility of various portions of the design. As
portions of the extension are implemented, the version number of the
extension has changed to reflect the portions of the standard provided.
This document describes the version 1.2 of the specification, the
partial implementations have version numbers less than that. Here's a
list of what each version provided:

        1.0: Released, but never used.  Relied on a number of
                constructs from the XF86DRI extension, such as a
                shared memory area (SAREA) to communicate changes in
                cliprects and window sizes, and

        1.99.1: Move the swap buffer functionality into the X server,
                introduce SwapBuffer request to copy back buffer
                contents to the X drawable.

        1.99.2: Rethink the SwapBuffer request as an asynchronous
                request to copy a region between DRI2 buffers.  Drop
                CreateDrawable and DestroyDrawable, update Connect to
                support different driver types and to send the
                authentication group.

        2.0: Awesomeness!

Compatibility up to 2.0 is not preserved, but was also never released.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


10. Relationship with other extensions

As an extension designed to support other extensions, there is
naturally some interactions with other extensions.


10.1 GLX

The GL auxilary buffers map directly to the DRI2 buffers... eh


10.2 DBE

The DBE back buffer must correspond to the DRI2_BUFFER_FRONT_LEFT
DRI2 buffer for servers that support both DBE and DRI2.


10.3 XvMC

We might add a DRI2_BUFFER_YUV to do vsynced colorspace conversion
blits.  Maybe... not really sure.


                             ⚙ ⚙ ⚙  ⚙ ⚙ ⚙


Appendix A. Protocol Encoding

Syntactic Conventions

This document uses the same syntactic conventions as the core X
protocol encoding document.


A.1 Common Types

┌───
    DRI2ATTACHMENT
        0x0     DRI2_BUFFER_FRONT_LEFT
        0x1     DRI2_BUFFER_BACK_LEFT
        0x2     DRI2_BUFFER_FRONT_RIGHT
        0x3     DRI2_BUFFER_BACK_RIGHT
        0x4     DRI2_BUFFER_DEPTH
        0x5     DRI2_BUFFER_STENCIL
        0x6     DRI2_BUFFER_ACCUM
        0x7     DRI2_BUFFER_FAKE_FRONT_LEFT
        0x8     DRI2_BUFFER_FAKE_FRONT_RIGHT_LEFT
└───
        Used to encode the possible attachment points.

┌───
    DRI2BUFFER
        4       CARD32  attachment
        4       CARD32  name
        4       CARD32  pitch
        4       CARD32  cpp
        4       CARD32  flags
└───
        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.


A.2 Protocol Requests

┌───
    DRI2QueryVersion
        1       CARD8                   major opcode
        1       0                       DRI2 opcode
        2       3                       length
        4       CARD32                  major version
        4       CARD32                  minor version
      ▶
        1       1                       Reply
        1                               unused
        2       CARD16                  sequence number
        4       0                       reply length
        4       CARD32                  major version
        4       CARD32                  minor version
        16                              unused  
└───

┌───
    DRI2Connect
        1       CARD8                   major opcode
        1       1                       DRI2 opcode
        2       3+(n+p)/4               length
        4       WINDOW                  window
        4       CARD32                  driver type name length
        n       CARD8                   driver type name
        p                               unused, p=pad(n)
      ▶
        1       1                       Reply
        1                               unused
        2       CARD16                  sequence number
        4       (n+m+p)/4               reply length
        4       n                       driver name length
        4       m                       device name length
        4       CARD32                  group
        12                              unused
        n       CARD8                   driver name
        m       CARD8                   device name
        p                               unused, p=pad(n)
└───

┌───
    DRI2Authenticate
        1       CARD8                   major opcode
        1       2                       DRI2 opcode
        2       3                       length
        4       WINDOW                  window
        4       CARD32                  authentication token
└───

┌───
    DRI2GetBuffers
        1       CARD8                   major opcode
        1       3                       DRI2 opcode
        2       3                       length
        4       DRAWABLE                drawable
        4       n                       number of attachments
        4n      LISTofDRI2ATTACHMENTS   attachments
      ▶       
        4       CARD32                  width of drawable
        4       CARD32                  height of drawable
        5n      LISTofDRI2BUFFER        buffers
└───

┌───
    DRI2CopyRegion
        1       CARD8                   major opcode
        1       4                       DRI2 opcode
        2       3                       length
        4       DRAWABLE                drawable
        4       REGION                  region
        4       DRI2ATTACHMENT          source
        4       DRI2ATTACHMENT          destination
        4       CARD32                  flags
        4       CARD32                  sequence
└───


A.3 Protocol Events

The DRI2 extension specifies no events.


A.4 Protocol Errors

┌───
    ERRORS
        Base + 0                Authenticate
└───
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg

Reply via email to