Just a few points all of this has been covered in detail before.
The terminal emulator and VT system need to be pulled out of the kernel. This is because they are single user, and it would take a lot of code to make them multiuser. VT's also implement the evil 'device driver multitasking'. That is where one app can load a complete state into the video card and then on VT swap the previous app has to recover. There is no protocol for saving VRAM, registers, etc. Other people have been working on this area: http://homepages.tesco.net./~J.deBoynePollard/Proposals/linux-console-daemon.html Boot time display is handled by a simple CRLF interface. The same interface is used to display panics. It is trivial to pull all of this out, just turn off CONFIG_VT. We are not going to get a single kernel interface for video cards. They are way too varied and implement the the same thing in too many different many ways. Mesa has the right model, exokernel. With exokernel each device driver exports their own set of IOCTLS. Mesa then provides a consistent API across all cards via a user space library. We also don't need an alphabet soup of Linux specific APIs: XAA, FB., EXA and whatever else is being devised. A single OpenGL|ES library would work just fine. The OpenGL people have offered to define extensions for 2D bitblit and fill to get the best performance from a low end card. One should note that there is a commercial OpenGL|ES implementation running in 100K on a cell phone framebuffer before declaring that OpenGL is too big and complex for Linux. The bottom line is that none of this is going to happen anytime soon, maybe not in the next ten years. Too many of the existing developers are concerned with total compatibility. They resist all change and only concentrate on bug fixes. The other developers all want to do everything their way, Linux graphics has all chiefs and no indians. Forward progress is stopped by internal politics. It's because of these political factors that I am suggesting exploring the GPGPU world. There are no preexisting Linux politics in that area. The other reason is the possibility of landing a sugar daddy. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
