Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

> One solution to this split is to build the system management console
> in-kernel using the existing fbdev code. A hot key can be used to
> access it or it will appear automatically on a panic. The system
> management console does not need acceleration, but it always has to
> work and work in any context (like interrupt context). Working in any
> context forces an implementation that is entirely contained in the
> kernel.

And what happens if that console data has been damaged by a wild pointer write 
in kernel?

This does have a practicle use, and the console data for the "System Console" 
is unlikely to get screwed with. I am just pointing out that there are 
problems even with your suggestions. I had already planned on something 
similar to this when I began working on a method to have the video drivers 
able to be added and removed at runtime. What I was planning on was using 
vgacon (for those systems that support it) as the system console and having 
tthe system default back to that should *anything* go wrong in the kernel. 
For the systems that don't support vgacon there is going to be a very minimal 
fbcon that will serve the same purpose.

Userspace helpers for modesetting and other simple tasks is no problem. When 
it comes to handling the acceleration, the DRI part  of the DRM 
infrastructure (the Userspace side of it, in other words) needs to be running 
and available. This is why X has to load the module. Providing that to 
userspace then become a concern, and the easiest way to do this is to have 
the DRI portion loaded and running inside a userspace daemon, either pinned 
into memory so that the OOM killer can't touch it, or running as a special 
process under init that will *always* get restarted if it dies.

Using a mass of userspace helpers, or requiring the applications to provide 
and load their own userspace drivers for the DRM/DRI system is, IMHO, not an 
option.

DRH