Messages in this thread | | | Date | Thu, 25 May 2006 19:17:13 -0400 | From | Jeff Garzik <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
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
- 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/
| |