Using HAL for X Server Config Properties?

[Dave Airlie]

On 10/8/05, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> On Fri, 2005-10-07 at 14:38 -0400, Jim Gettys wrote:
> > There are a number of things going on here:
> >
> > 1) I think we are mostly agreed on probably using dbus to talk to the X
> > server to control configuration.  There isn't any particular Linux
> > dependency to dbus that I can see.
> >
> > And configuration can get complicated, with many different input devices
> > and potentially more than one seat on a system.
>
>  .../...
>
> I've been discussing the purely output device aspect of things a few
> times in the past with Keith and others, and it seems a good approach
> here would be to go toward something like this (I'm throwing here a
> bunch of the things that we have discussed, it's open for correction of
> course). Maybe we could start from that, define each points more
> precisely, and move toward a more formal definition, though I have the
> gut feeling that a prototype implementation is worth 10 architecture
> documents :)
>
>  - The actual hardware mode setting interface split from the server
> itself.
>
>  - The above interface is provided by a daemon/server (protocol to be
> defined, possibly dbus based) which itself has loadable backend modules.
> It interfaces to whatever operating system interface can notify it of
> addition/removal of display adapters.
>

I've talked about this a lot before  and I will be talking about it at LCA...

But can we at least sort out one thing (I believe that this question
isn't as easy at it looks..) what is a mode?

What do we need to define a complete mode? what needs to be passed
over the DBUS connection from the mode setting server to the client so
that the client has enough information to make a decision on it...
just a name? do we want the client to have "a details button" so the
user can get more information.. if so do we include that in the
primary mode list or have the client request it afterwards?

I'll open the bidding at the Linux fbdev fb_var_screeninfo:
struct fb_var_screeninfo {
        __u32 xres;                     /* visible resolution           */
        __u32 yres;
        __u32 xres_virtual;             /* virtual resolution           */
        __u32 yres_virtual;
        __u32 xoffset;                  /* offset from virtual to visible */
        __u32 yoffset;                  /* resolution                   */

        __u32 bits_per_pixel;           /* guess what                   */
        __u32 grayscale;                /* != 0 Graylevels instead of colors */

        struct fb_bitfield red;         /* bitfield in fb mem if true color, */
        struct fb_bitfield green;       /* else only length is significant */
        struct fb_bitfield blue;
        struct fb_bitfield transp;      /* transparency                 */

        __u32 nonstd;                   /* != 0 Non standard pixel format */

        __u32 activate;                 /* see FB_ACTIVATE_*            */

        __u32 height;                   /* height of picture in mm    */
        __u32 width;                    /* width of picture in mm     */

        /* Timing: All values in pixclocks, except pixclock (of course) */
        __u32 pixclock;                 /* pixel clock in ps (pico seconds) */
        __u32 left_margin;              /* time from sync to picture    */
        __u32 right_margin;             /* time from picture to sync    */
        __u32 upper_margin;             /* time from sync to picture    */
        __u32 lower_margin;
        __u32 hsync_len;                /* length of horizontal sync    */
        __u32 vsync_len;                /* length of vertical sync      */
        __u32 sync;                     /* see FB_SYNC_*                */
        __u32 vmode;                    /* see FB_VMODE_*               */
        __u32 rotate;                   /* angle we rotate counter clockwise */
        __u32 reserved[5];              /* Reserved for future compatibility */
};

Now do we need all that information it is quite a lot....

Dave.