On Wed, Mar 23, 2011 at 6:30 AM, Keith Packard <[email protected]> wrote: > On Tue, 22 Mar 2011 10:27:13 +1000, Dave Airlie <[email protected]> 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
http://cgit.freedesktop.org/~airlied/xserver/log/?h=proto-screens has my first tenative step in what I hope is the correct direction All it does is split the protocol screen struct out from the screen struct and reworks the code to get the screen struct via the protocol screen in all the right places. I may have gone a step too far with allowing the 1:n mapping between protocol screens and screens, but for xinerama this does allow a few cleanups. This also looks like it will make hotplug/switchable graphics a bit easier. Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
