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

Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]



On Thu, Oct 24, 2002 at 05:30:21PM -0500, Manoj Srivastava wrote:
> 
> 	Good. Now if we hear from Herbert on this issue, perhaps we
>  can  proceed.

Thank you for bringing this to my attention, I was not aware that this
matter is being discussed here.

Firstly, let me answer this point.

>  Eduard> As stated, nothing will break if vesafb is just available in the kernel.
>  Eduard> If a user enables it, sHe should know whether the video card supports it
>  Eduard> (most do). In contrary, when the user switches from existing,
>  Eduard> vesafb-enabled configuration to a Xu's kernel, he only gets a 
>  Eduard> _black screen_. No warnings, no hints.

This is indeed a serious bug, and it has been fixed in 2.4.19-3 where
the kernel will ignore the vga setting if VESA is not compiled in.

So the remaining issue is whether we should compile VESA support in.
My position is no and let me explain why that is.

Firstly I argue that VESA FB is only needed by a very small proportion
of our i386 users.  This stems from the fact that the great majority of
them use X and thus have no need for frame buffer drivers, or at least
not the generic VESA FB.  For those who have to stay out of X and still
use an FB driver, there is a plethora of FB drivers suited to specific
chipsets, most users with new video cards can use these.  And for
those unfortunate enough to have an unsupported card, there is always VGA16.

Thus I contend that only a small minority of people would benefit from
the inclusion of VESA FB.

This in itself is not a reason to exlude VESA FB.  In fact, I have no
qualms about including it as a once-off event.  However, I'm excluding
it as a matter of principle.  There is a number of other device drivers
in the kernel which have not be modularised.  They're similar to VESA FB 
in that they're only needed by a small number of users.  If I were to
include VESA FB, then it would be difficult for me to argue why the others
should not be included where there is no adverse effect to other people.

Although the inclusion of one such driver has little impact on the overall
kernel, the inclusion of all of them would render the kernel useless since
it would be so big that projects like debian-installer would have to
seek a custom kernel which is something they've been trying to avoid.

This is the main reason why I object to the inclusion of VESA FB in
its current non-modularised form.  There are other reasons well.  For
instance, I would like to distribute fbcon in a modularised form.  Having
VESA FB compiled in would remove that flexibility that we would have
otherwise.

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.
-- 
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: