Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Jason Gunthorpe <jgg@debian.org> wrote:
>
> 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
> boot.
>
> 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.
The fact that the mode switching has to be compiled in statically does
not preclude the modularisation of vesafb since it is already a separate
piece of code goverened by a different CONFIG option.
> 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.
If VESAFB is modularised, then you would load it from the initrd just
like any other essential module. In fact, in future it may become
the modus operandi with the advent of early user space.
As a proof that this already works, just look at how TGAFB is loaded on
alpha. It is completely analogous to this situation except that the
video mode switching is already done.
> 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.
Console drivers per se probably aren't that bad. Although even there,
VESAFB is certainly not unique. The other non-modularised console
drivers include the serial console, as well as the parallel console.
The former is currently included while the latter isn't.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: