Re: OpenGL-based framebuffer concepts

[Jeff Garzik <jeff@garzik.org>]

Dave Airlie wrote:
> So far we have no memory management, and most of the plans I've seen
> involved using a userspace system to do it, really we just want the
> fbdev driver to be able to ask the DRM, so where the hell is the
> frontbuffer, if the DRM is loaded and if it isn't just say I'm using
> here.

The kernel will need to do some amount of arbitration, some amount of 
scheduling between competing processes.  Doing a lot of that in 
userspace seems a bit questionable.


> And won't as long as you fight against it, we don't have to force X to
> use it, we have to make it an option in X that distros turn on... we
> have to let the X people keep doing their drivers the way they do
> drivers... I'm still not convinced putting modesetting in kernel is at
> all necessary, I think a simple MMIO parser to stop bad commands from
> getting to the hardware is all we should need, modesetting normally
> consists of a small number of operations.
> 
> Write register,
> Read register,
> Wait for something to happen (vblank, bit set in a register X times..)

Kernel needs to do suspend/resume, interrupt handling, DMA mapping, ...

Further, whatever the Linux kernel chooses to do, the X server will follow.

History has proven that it is COMPLETELY BROKEN to allow X to dictate 
these basic architectural decisions.  X11's ancient and broken PCI bus 
handling is a testament to this.  Tons of polling everywhere, rather 
than cleanly handling events in interrupts, is a further testament.

If we do it right, X will follow.  As will FreeBSD and other OS's.

	Jeff