Re: OpenGL-based framebuffer concepts

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

On Monday 29 May 2006 21:23, Jeff Garzik wrote:
> Pavel Machek wrote:
> > These are very reasonable rules... but still, I think we need to move
> > away from vgacon/vesafb. We need proper hardware drivers for our
> > hardware.
>
> I agree we need proper drivers, but moving away from vesafb will be
> tough... moving away from vgacon is likely impossible for many many
> years yet.

After my rant last night I spent some time thinking... Thanks to a private 
message from Dave Arlie today the conclusion I came to proved correct.

The model I was working towards, where there is a low-level mediation layer 
for the video-hardware is what is needed. The argument was over where to 
start, and I started at the wrong end.

> Once proper hardware drivers exist, you will still need to support
> booting into a situation where you probably need video before a driver
> can be loaded -- e.g. distro installers.  Server owners will likely
> prefer vgacon over a huge video driver they will never use for anything
> but text mode console.

vgacon will likely never be removed from the kernel. If the direction Dave has 
told me things should go in works, vgacon will be needed for distro 
installers, servers and early boot. The fbdev system itself will survive for 
those servers where people want it and for the embedded people that depend on 
it. WHat is likely to change is the common user...

I'm making an assumption here based on several statements Dave made in a 
private e-mail to me, but the direction things would likely go for "normal" 
users is that the DRM system will be used for everything. If this is the 
case, then the likely best solution for all kernel errors would be 
transferring control of the primary display and input devices to vgacon and 
switching to it's preferred mode. Done properly the driver state (at an oops) 
could be stored and then restored after the user acknowledges the error 
(unless the user has configured the system not to wait on a recoveable 
error).

Before I can restart my work at trying to move the kernel graphics system 
forward, I would like to apologize to people for my behaviour.

DRH