internal screen concept

[Keith Packard]

On Tue, 22 Mar 2011 10:27:13 +1000, Dave Airlie <airlied at gmail.com> wrote:

> My first solution involves throwing the XFree86 DDX out and starting
> again, but this didn't seem like it would be acceptable.

Yeah, wrecking every driver all at once is probably not a winning plan.

> a) add concept of internal screen to ScreenRec and ScrnInfoRec, add
> new value  screenInfo.numProtocolScreens, add lots
> of if (screenInfo.screens[i].internalScreen) continue to places where
> the protocol meets the screen info struct, and we want to skip
> internal screens.

I think this idea of isolating the driver from the protocol objects is
the right plan here. However, I think we want to leave all of the
existing objects to be used in the driver interface and go look at
fixing the DIX layer to use new datatypes for the protocol objects. I
think any protocol-visible object which stores driver-specific data in
DIX-visible fields would need to be changed. Off the top of my head,
that includes:

 Screen         - A million function pointers
 Window         - Clip lists
 Pixmap         - Actual pixels
 GC             - ops/funcs plus clipping
 Picture        - clipping

This is essentially what Xinerama did, the difference being that
Xinerama used the DIX data structure for both the protocol-visible
objects and the driver-visible objects. Using separate objects for the
protocol-visible versions should make the code a whole lot cleaner.

Eventually, we might have the driver-visible objects point back at the
protocol-visible objects to extract protocol state from there, rather
than replicating it.

This might also be a good time to eliminate windows from the driver API
and only pass pixmaps around.

-- 
keith.packard at intel.com
-------------- 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-devel/attachments/20110323/bd6f6565/attachment.pgp>