DRI2 Protocol Spec Draft

[Michel Dänzer]

On Tue, 2008-09-09 at 08:46 -0700, Keith Packard wrote:
> 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:

Sounds like the DRI1 authentication mechanism. :)


> > 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.

GLX_EXT_texture_from_pixmap needs the real front buffer.

Consider me convinced that it doesn't need to return any position
information though.


> >  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.

Some GLX synchronization extensions provide information about whether a
buffer swap hit or missed the target.

> 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.

Yeah, something like that could work.


> >  Oh, and I think it should take relative
> > sequence numbers as well as absolute ones.
> 
> Yeah, GL does kinda require this.

Rather driconf vblank_mode=3. Hmm, though that would also require
DRI2CopyRegion not to execute the copy if the target was missed...

Generally, if DRI2CopyRegion seriously wants to be useful for
synchronization purposes, it probably needs to provide at least the same
functionality as the DRM vblank related ioctls.

Of course, for redirected windows it should really synchronize to the
compositing manager rather than to the display hardware directly, but
I'm not sure that matters at this point.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer