[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OpenGL-based framebuffer concepts
    On 6/1/06, Ondrej Zajicek <> wrote:
    > On Wed, May 31, 2006 at 12:39:19AM -0400, Jon Smirl wrote:
    > > >Yes, but I have accepted that there is a certain direction and order the
    > > >maintainers want things done in. For this reason I can't just leave DRM
    > > >alone.
    > >
    > > fbdev (Antonino A. Daplas <>) and DRM (Dave Airlie
    > > <>) have two different maintainers. I have not seen
    > > Tony comment on what he thinks of Dave's plans so I don't know what
    > > his position is how driver merging can be acomplished.
    > Is there some document describing long-term direction or plans for this?
    > (another than
    > I googled for last Kernel Summit mentioned here but didn't found anything
    > specific.

    I wish everyone involved would write up their positions. It is very
    hard trying to determine what someone's overall plan is based on
    hundreds of emails spread over multiple lists.

    Half of what we are auguring about probably isn't even a real issue,
    it is just mistaken perceptions of what the other parties want.

    It doesn't even need to be a global write up. I'd just like to see
    design write ups for the kernel issues around fbdev, console, DRM
    integration, boot display, device nodes, multiuser console, etc. Leave
    out everything around X and OpenGL. Since there aren't very many ways
    to solve these problems I suspect everyone is closer together than we
    may think.

    Without specifying a design here are a few requirements I would have:

    1) The kernel subsystem should be agnostic of the display server. The
    solution should not be X specific. Any display system should be able
    to use it, SDL, Y Windows, Fresco, etc...

    2) State inside the hardware is maintained by a single driver. No
    hooks for state swapping (ie, save your state, now I'll load mine,

    3) A non-root user can control their graphics device.

    4) Multiple independent users should work

    5) The system needs to be robust. Daemons can be killed by the OOM
    mechanism, you don't want to lose your console in the middle of trying
    to fix a problem. This also means that you have to be able to display
    printk's from inside interrupt handles.

    6) Things like panics should be visible no matter what is running. No
    more silent deaths.

    7) Obviously part of this is going to exist in user space since some
    cards can only be controlled by VBIOS calls. Has anyone explored using
    the in-kernel protected mode VESA hooks for this?

    8) The user space fbdev API has to be maintained for legacy apps. DRM
    can be changed if needed since there is only a single user of it, but
    there is no obvious need to change it.

    9) there needs to be a way to control the mode on each head, merged fb
    should also work. Monitor hotplug should work. Video card hot plug
    should work. These should all work for console and the display

    10) Console support for complex scripts should get consideration.

    11) VGA is x86 specific. Solutions have to work on all architectures.
    That implies that the code needed to get a basic console up needs to
    fit on initramfs. Use PPC machines as an example.

    12) If a driver system is loaded is has to inform the kernel of what
    resources it is using.

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

     \ /
      Last update: 2006-06-01 19:02    [W:0.024 / U:107.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site