On Wed, 23 Mar 2011 16:03:59 +1000, Dave Airlie <airl...@gmail.com> wrote:

> 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.

Would be nice to have the protocolstr.h file

However, looking at the code, I'm not sure I get the big plan. Things
like the new connection setup code assume that for each protocol screen,
the client visible information will be precisely mirrored in the 0th DDX
screen in that object. Are we sure we want to do that? Would it be
better to have the client-visible screen information directly present in
the protocol screen?

Similarly, for input, we want to hide DDX screens from all of the input
code; they aren't relevant at all.

Here's what I expect to see the ProtocolScreen and Screen look like:

typedef struct _ProtocolScreen {
    int                 myNum;  /* index of this instance in ProtocolScreens[] 
*/
    short               x, y, width, height;
    short               mmWidth, mmHeight;
    short               numDepths;
    unsigned char       rootDepth;
    DepthPtr            allowedDepths;
    unsigned long       rootVisual;
    unsigned long       defColormap;
    short               minInstalledCmaps, maxInstalledCmaps;
    char                backingStoreSupport, saveUnderSupport;
    unsigned long       whitePixel, blackPixel;
    short               numVisuals;
    VisualPtr           visuals;
    WindowPtr           root;
    int                 num_screens;
    ScreenPtr           *screens;
} ProtocolScreenRec;

typedef struct _Screen {
    int                 myNum;  /* index of this instance in Screens[] */
    short               x, y, width, height;

    ProtocolScreenPtr   *protocol_screen;

    GCPtr               GCperDepth[MAXFORMATS+1];
                        /* next field is a stipple to use as default in
                           a GC.  we don't build default tiles of all depths
                           because they are likely to be of a color
                           different from the default fg pixel, so
                           we don't win anything by building
                           a standard one.
                        */
    PixmapPtr           PixmapPerDepth[1];
    pointer             devPrivate;
    ScreenSaverStuffRec screensaver;

    ... A million function pointers ...

    /* set it in driver side if X server can copy the framebuffer content.
     * Meant to be used together with '-background none' option, avoiding
     * malicious users to steal framebuffer's content if that would be the
     * default */
    Bool                canDoBGNoneRoot;
} ScreenRec;

> This also looks like it will make hotplug/switchable graphics a bit
> easier.

That is my fervent hope.

-- 
keith.pack...@intel.com

Attachment: pgpx13PlSmJsh.pgp
Description: PGP signature

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to