DRI2 Protocol Spec Draft

[Keith Packard]

On Wed, 2008-09-10 at 14:09 -0400, Kristian Høgsberg wrote:

> Everybody can talk to the DRM and create
> a token, but only if you can pass it to the server over DRI2 protocol,
> can you authenticate.

Oh, so the cookie in the protocol is a client identifier of some kind.

In any case, 32 bits of unique id isn't exactly high security; my
thought was that we should allow the system to use a longer key to avoid
spoofing.

> I'd say the two schemes are pretty much equivalent in complexity and
> in what options we have for narrowing down access per client as you
> suggest.  Pros and cons of the two schemes as I see it is that your
> scheme eliminates the DRI2Authenticate request from the protocol, but
> requires a random cookie to be generated, which is a little icky...
> how many bits etc?  The old scheme is well established and the extra
> request isn't really a concern - it's async.

The cookie could be per-X server if there wasn't any desire to provide
finer-grained access control.

And, 'how many bits' is precisely the question I'd want to leave to the
system, but certainly more than 32.

> Do we need this?  When will the client have a better idea of which
> pipe a window is on than the X server?

Yes, whenever the two screens overlap.

> So for DRI2CopyRegion flags, something like this:
> 
>     #define DRI2_VSYNC_DONT_CARE 0x0
>     #define DRI2_VSYNC_ABSOLUTE 0x1
>     #define DRI2_VSYNC_RELATIVE 0x2
>   ( #define DRI2_VSYNC_RESERVED 0x3 )

Sounds good to me.

-- 
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/20080910/0de7f099/attachment.pgp>