DRI2 Protocol Spec Draft
keithp at keithp.com
Wed Sep 10 14:10:29 PDT 2008
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
> 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...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg