internal screen concept

[Dave Airlie]

On Wed, Mar 23, 2011 at 6:30 AM, Keith Packard <keithp at keithp.com> wrote:
> 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

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.