DRI2 Protocol Spec Draft

[Keith Packard]

On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote:

> I think it'd be good if the authentication stuff could be made/kept
> optional or at least not DRM specific. (I'm not sure GEM or the DRM in
> general is within scope of this spec at all)

I have to admit that I'm not very excited by the existing authentication
protocol.

What we want is a way to let applications identify themselves with the
kernel and 'prove' that they have permission to access kernel objects.

It seems like having the X server return a 'cookie' that the client
could use with the kernel module might make things simpler:

┌───
    DRI2Connect
        window: WINDOW
        type: STRING
      ▶
        driver: STRING
        device: STRING  -- device file name
	auth-data: LISTofCARD8
└───

	'auth-data' is an arbitrary array of bytes which the client
	passes to the direct rendering system to validate the client's
	access of direct rendering objects created by the X server.

It seems like this offers precisely the right guarantee -- the client
proves to the kernel that it is connected to the X server and thus
should be granted permission to access the X server objects. Under some
tighter access control mechanisms, the 'auth-data' could even be
generated per-client so that the client would only have access to a
sub-set of X server objects.

> I do wonder if DRI2GetBuffers should return the drawable position
> relative to the origin of each buffer... guess it isn't strictly
> necessary except maybe for the real frontbuffer.

One of the requirements in DRI2 is that the 'real' front buffer be
invisible to applications; there's no way the application can sensibly
use those contents. Moreover, the drawable position may change without
any warning due to window configuration.

> For DRI2CopyRegion, you're leaving it to the DDX driver to pick the CRTC
> to synchronize to? I'm not sure that'll work too well with overlapping
> viewports, where the user may want to choose which CRTC to synchronize
> to for each application.

Yeah, I don't see a good way to avoid this, and the client can always
pass in 'Automatic' (0) and let the server pick the 'right' one.

>  This request also still seems to be missing
> return values for the sequence number when the copy is expected to take
> place and tokens for synchronization of direct rendering to the
> source/destination buffer.

Eliminating the reply avoids a round trip, so I'm in favor of not
providing any if it's not strictly necessary.

I don't know if the GL api requires us to provide the expected sequence
number back to the application.

For synchronization, we should expect the kernel module to perform this
automatically -- once the X server has processed this request, the
kernel can pend further rendering to the source buffer until the copy
has finished. That would, of course, require that the application know
that the kernel has received the copy command from the X server -- so
the client would need to get something from X server indicating that it
had finished processing the Copy request. The easiest thing to use would
be a reply, but we'd structure the library so that the client wouldn't
pend on the reply and could block just before touching the back buffer
again.

Note that there isn't any synchronization on the real front buffer; that
isn't a legal target for direct rendering.

>  Oh, and I think it should take relative
> sequence numbers as well as absolute ones.

Yeah, GL does kinda require this.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080909/2b2e181f/attachment.pgp>