Re: [PATCH] neofb patches

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> > 
> > DRM and fbdev must merge so i repeat: just a single
> > kernel entity should own FIFO queues, shared locks,
> > DMA, the framebuffer, IO registers, interrupts, etc.
> 
> A small low-level driver could handle this, which both the framebuffer
> device and the DRM use. Linus has proposed this approach, and I must say
> I like it.

The idea here is to have a small per-card low level driver (no common
API or little of it) used to do the IRQ, fifo/ring management & blasting
of registers. Everything else is client of this driver, including
possibly fbcon. That also means we move all of mode management to
userland, which I tend to slowly agree with. Remember that in 2.7, we
may have an initramfs with klibc etc... thus we can have userland code
shipping along with the kernel.

I started working on a userland API do deal with all of the mode
management cruft that could be implemented either on top of fbdev or
something else, but I didn't have time to finish. And I think Jon Smirl
started his own different thing (of course) there...

One of the ideas we had after discussing with Keith Packard that the
model should be a library that deals with all the settings of the
displays, the geometry of the desktop(s) (relative position of screens),
modes, etc... That library would interface to the various drivers via
backend libraries and would broadcast via dbus the environment changes
so that things like window managers, x servers, or whatever else can
adapt. Applications would talk directly to the library.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click