On 5/21/07, Jesse Barnes <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
