Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
#include <hallo.h>
* Herbert Xu [Sun, Nov 03 2002, 10:29:54PM]:
> > 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.
Well, could you explain the connection between a config option and the
actuall feasibility?
> > 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
s/If/When/, that is the question. I do not see anybody working on
modularizing it, do you? From my point of view, the things are clear:
No kernel developer really needs it or has too much spare time to work
on modularisation of VESAFB. The driver is so small that there is no
problem including it into the kernel. We can either wait for a wonder
that will never happen, or you can rewrite the driver by yourself, or
admit that including it is not that bad and just do it.
> 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.
Really? I do not know about "compatibility modes" on Alpha such as
the sick oldcompatible real mode on i386.
Gruss/Regards,
Eduard.
--
Debian: All the power, no red hats, no green chameleons.
Reply to: