Xgl/Xegl future?

[Adam Jackson]

On Sunday 21 August 2005 22:02, Michel Dänzer wrote:
> On Sun, 2005-08-21 at 20:53 -0400, Adam Jackson wrote:
> > If you are direct rendering, then you need some cooperation over the
> > protocol: the server needs to tell the client to render offscreen rather
> > than to the front buffer, and the client needs to inform the server of
> > the offscreen buffer's location.
>
> Even ignoring issues with the server trusting that kind of information
> from clients, I think that's backwards, AFAIK the vast majority of
> clients creates the window via X alone and only then sets up the GLX
> stuff.

Okay, so that would suggest that the server is responsible for creating the 
offscreen buffer for redirected clients to render into.  Which sounds fine.

And that's even relatively easy to implement.  DRICreateDrawable could return 
(say) BadMatch if the drawable is redirected, which would prompt the client 
to get the handle of the offscreen buffer from the server through some new 
DRI protocol.  And then to handle the case where the compmgr is started while 
the DRI client is running, you'd bump the drawable timestamps and return 
BadMatch on the next DRIGetDrawableInfo request for the affected window, 
which would then trigger the same rebinding operation.  And you could 
probably invert that process when the compmgr goes away.

Remember that we're positing the existance of a memory manager that makes the 
above actually possible.

> > The only challenge is deciding what channel to do that
> > over, SAREA or DRI protocol or maybe GLX protocol + DRM interface.
>
> In which case this wouldn't be completely abstracted in the GL
> implementation, and Xgl wouldn't be vendor neutral.

Like any interesting GLX extension, you'll have a frontend in the GLX engine 
and a backend in the DDX driver (or DRI driver, someday).  My reference to 
which channel to go through is just about how the client and server 
communicate the device-specific info.

From the GL client perspective this is all just binding pictures to textures.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050821/cf75d12a/attachment.pgp>