lkml.org 
[lkml]   [2007]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] enhancing the kernel's graphics subsystem
    On 5/21/07, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
    > On Monday, May 21, 2007, Jesse Barnes wrote:
    > > > There is more to fbdev than mode setting. It is also how non-x86
    > > > platforms achieve their boot display. How will boot display be handled
    > > > with the your design? What about console display on non-x86 platforms?
    > > > Loading both fbdev and the new code puts us right back into the
    > > > multiple driver fight we have today.
    > >
    > > Maybe you should take a look at the patches. :) The code I posted
    > > actually creates an fb device as a slave of the DRM device, and uses
    > > that for the boot console. Once you've booted, you can use the new
    > > interfaces to do whatever you want with the graphics device... though it
    > > doesn't create /dev/fb* devices per-CRTC like you seem to want, it's
    > > really easy to do the equivalent with a small userspace program (though
    > > I haven't actually tested sharing of buffer objects, it should work).
    >
    > Actually, scratch that last bit. I forgot about a recent change alanh
    > committed that did just that: per-CRTC FB devices. So please take a
    > close look (modesetting-101 of mesa/drm git at freedesktop.org) and let me
    > know if you see any gaping holes.

    Here are some of the goals that I believe a rewrite of the graphics
    system should address:

    1) Be upwards compatible with the existing fbdev drivers. This lets us
    avoid rewriting the 90 existing drivers. New drivers shouldn't break
    any old apps.

    2) Address the long outstanding issue of multi-seat at the console
    level. My solution to this is the one device per CRTC model.

    3) Eliminate the need for a root priv controlling process. Get rid of
    the potential for a security hole.

    4) OOPS should always display even if in a graphics mode

    5) Support Secure Attention Key (SAK).

    6) Eliminate the existing VT swap driver free for all. I would compile
    out the VT layer and replace it with a compatible API that enforces
    some sanity.

    7) Support Unicode on the console

    8) Allow multiple user space graphics systems to run. These user space
    systems should not touch the hardware, instead they ask the kernel
    driver to manipulate the hardware on their behalf. Of course the
    kernel driver is only the minimum code needed to arbitrate control of
    the resources - it doesn't do things like implement drawing
    algorithms.

    9) Booting on non-VGA hardware still needs to work.

    10) Support things like cloning and output device selection.

    Of course a driver doesn't need to support all of this in its first
    release. What's important is that the new architecture support all of
    these features so that we don't end up rearchitecting it yet again.

    Other people may add more things to this list. Let's get the design
    right this time around and address all of the known problems.

    --
    Jon Smirl
    jonsmirl@gmail.com
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-21 19:07    [W:4.184 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site