[lkml]   [1999]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectLinux Graphics Architecture (format fixed)
    A quick survey of the existing Linux Graphics (de facto) Architecture
    reveals a mess of applications, libraries, and most recently the
    framebuffer device, all contending for the graphics hardware. The major
    opponents seems to be: XFree86, /dev/fb, KGI (Kernel Graphics Interface
    - GGI project) and SVGALib.

    The current "solutions" to this hardware contention are at best short
    term solutions such as XFree DGA, XF86_FBDev, "framebuffer aware"
    XF86_SVGA, GGI-over-anything and SVGALib-over-GGI, and the more
    interesting X-over-GGI/KGI (XGGI).

    The real solution to eliminating contention and incompatability amongst
    these applications and libraries is a device driver interface to the
    graphics hardware. This would have many benefits:

    o Eliminate hardware contention and X/framebuffer/application
    o Provide portable direct-to-hardware accelerated graphics, both within
    and outside of of X
    o Fully support new graphics cards via device driver implementation
    o Eliminate hardware driver implementation redundancy

    This is hopefully all rather obvious and non-contentious. The
    interesting part is how to get there from where we are now with the
    minimum of effort. I believe that the GGI project already contains
    components that can be repackaged to provide what's needed.

    I propose the following:

    o Linux standardizes on a graphics device driver interface
    o The driver interface, /dev/kgi, be based on the existing KGI drivers
    o The XGGI X-server bypasses GGI and gets merged back into XFree86 as
    o That a new graphics library, libkgi, be written for use by

    The graphics library's architectural purpose would be to shield
    applications from differing capabilities of /dev/kgi drivers for
    differing graphics hardware. The idea would be that /dev/kgi drivers
    only *need* implement some minimum core framebuffer like functionality,
    and that device capability flags indicate whether higher level features
    are implemented. Where a feature is not implemented, the graphics
    library itself would implement it in terms of lower level features.

    This graphics library would therefore allow a single accelerated
    device-ignorant XF86_KGI (or any other graphics application), to run on
    top of graphics hardware that only supported a minimal "framebuffer
    level" /dev/kgi. This is a much more general solution than XF86_FBDev.
    Additionally, if someone wanted to extend the /dev/kgi interface to
    support some new hardware acceleration feature, then this could be made
    portable via also providing a libkgi implementation.

    It seems that we could have a very smooth transition to this
    architecture. We would keep /dev/fb, and would have a generic fb_kgi
    /dev/kgi driver that would just implement minimum framebuffer level
    functionality via pass-thru to /dev/fb. The initial libkgi would just
    pass-thru to /dev/kgi. Initially XF86_FBDev would still be needed by
    people without a /dev/kgi KGI driver for their graphics card, but as
    soon as libkgi provided missing capability implementation then
    *everyone* could use the single XF86_KGI.

    Now the bad news! I don't have time to implement this myself. It does
    seem however that the initial work could be assumed by the GGI project
    *if* there are people there who are interested. Maybe there are other
    people who would also be interested in what would be quite a glamorous
    and high-profile project, particularly if Linus were to bless it.

    Of course the first step is to get some feedback, to see if the
    consensus is that this is a desirable way to go forward...

    Ben Bridgwater

    P.S. Please CC: any replies to myself.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.022 / U:5.312 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site