Using HAL for X Server Config Properties?

[Benjamin Herrenschmidt]

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

I think it's mixing too many different things. The mode/timing and the
pixel format are completely orthogonal things. I'm not sure they should
be in the same "structure" (whatever "structure" means in our protocol).

I think xoffset/yoffset should be separate. We need a fast-path to
change them without having to go through a full mode change (though it's
reasonable to provide a kernel/dri call for that I suppose).

Same goes with {x,y}res_virtual, I'm not sure they are related... The
problem here is even more sneaky. Who is dealing with the memory
management of the framebuffer in that big picture and thus, who is
responsible for "allocating" the bit of framebuffer that will be used
for scanout on a given CRTC ?

If the "client" allocates those and feed them to the mode server, we may
have a security issue (who enforces it ?). If the allocator is in the
kernel DRI or in the mode server, then the "client" could allocate the
scannout pixmaps separately, and then pass a "token" to them to the mode
server while setting a mode. That would define xres_virtual,
yres_virtual ... and one missing in fb_var_screeninfo which is the
pitch.

My idea thus would be to have something along those lines in the
configuration of a screen:

(RW = read/write: can be set by client, RO = read only, provided by
server only, OPT = optional)

 <region> : RW : allocation token (this is a handle to a previously
allocated pixmap to use as a scanout). Can be 0 initially in the
configuration passed to the mode server to have it auto-allocate a
pixmap of the provided xres/yres (and subsequently return the new token
when reading back the configuration).

 <format> : RW : pixel format (possibles values to be defined)

 <modelist> : RO,OPT : modelist handle (the server keeps the modelist
separate to avoid too much duplication). Handle to the modelist
applicatble to this screen
 
 <mode> : RW,OPT : mode handle (handle to a mode in one of the server
kept modelists to be applied to this screen)

 <timings> : RW,OPT : detailed timings. The client can ommit the mode in
a mode setting request and provide a detailed timing instead. When
setting a mode using the <mode> argument, <timings> will contain the
resulting timings if available

Note that it would maybe be useful to open the door to proprietary
options to be supported by some drivers. To avoid collision, the format
of the option names is <DRIVERNAME,option>

Details such as monitor characteristics should be in a separate
structure.

> 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.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg