Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
#include <hallo.h>
* Herbert Xu [Fri, Oct 25 2002, 06:50:08PM]:
> 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
I strongly object to this attitude. Shall we start argumenting for
removing m86k arch this way? At least many laptop users wish to have
vesafb since it is the only way to get shart and fullsized console
picture. I know enough users that wish a graphical console, and their
hardware is not supported by any other framebuffer driver (except of
vga16, of course).
> 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.
VGA16 as replacement is a joke - and you know this.
> 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
Examples please. Good examples.
> 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.
You have already began to do so with much larger pieces of code, ie.
quota support. Remember, we are talking about support for a hardware
component that is available in almost every client system, not some
random joystick driver.
> 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.
Who exactly needs this flexibility? Your kernel packages are for
_users_.
> BTW, there is absolutely no reason why the VESA FB driver cannot
> be modularised. The switching of video mode occurs independently
As said, it is said to be not trivial.
Gruss/Regards,
Eduard.
--
<Alfie> AAARGH, bin ich deppert!
-- #debian.de
Reply to: