ajax at nwnk.net
Sun Aug 21 19:32:32 PDT 2005
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg