[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console

On Sat, 2 Nov 2002, Ian Jackson wrote:

> So, would everyone else please vote ?  If you don't have an opinion or
> don't want to vote, please explicitly abstain.  That will shorten the
> voting period due to the `no longer in doubt' rule.

I agree with Ian's assement. So count this as a 'yes' vote.

Sorry I didn't have time to speak up during the discussion, but since I've
worked with the VESA calls and x86 VGA hardware quite abit in the distant
past let me chime in about the non-modularity bit..

Eduard had this in email from from the VESA FB author:

> No.  vesafb depends on the VGA BIOS activating the graphics mode (which
> is done in real mode startup code).  Thus it works on nearly all
> graphics cards on earth, but it also has a few drawbacks:  Limited to
> flickering 60Hz standard vesa modes, no mode switching at runtime, it's
> very slow, ... 

This explains the very strong technical reason why vesafb and fbcon have
to be compiled in statically. Basically, the VESA spec defines a set of
real mode BIOS calls to do mode switching and interrogate some information
about the new video mode. These must be executed in real mode, and the
only time the kernel is running in real mode is in the earliest stages of

The calls cannot be made _ever_ once the kernel has been booted unless you
resort to such trickery as using a BIOS emulator like Gerg alluded too.
The kernel simply has no mechanism for calling real mode x86 BIOS code.

Herbert mentioned this:

> BTW, there is absolutely no reason why the VESA FB driver cannot be
> modularised.  The switching of video mode occurs independently of it so
> it can be loaded just as another module.  If anybody could send me a
> patch doing just that, I'd be most happy to include VESA FB. 

Which I do not belive is correct. Once the VESA call has been made to
switch the framebuffer from cell mode (ie text mode) to bitmap mode the
normal text console driver will stop working completely. If the kernel
does not immediately boot and begin using vesafb+fbcon it will no longer
be able to display anything.

VESAFB will also be unique in this case, so the slippery slope Herbert is
afraid of can easially be stopped by recognizing that it truely is a
special driver.


Reply to: