Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
On Fri, Oct 25, 2002 at 01:31:24PM +0200, Eduard Bloch wrote:
>
> > 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
What attitude? The sentence you quoted is just a premise for the
conclusion below.
> 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).
Well the laptop users that you know seem to be rather different
from those that I know. The people who I know either use X or
are quite happy with text in vga16.
> VGA16 as replacement is a joke - and you know this.
It's quite useable for laptops in text mode at least.
> > 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.
arpd, sch_atm, lp_console, nfs_root, ...
> 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
Well It's my job as the maintainer to make such decisions. I have
decided that quota is of general interest and irreplaceble while
vesafb is not.
> > 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_.
The flexibility to modularise fbcon. You may wish to use an alternative
implementation for instance.
> > 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.
I certainly see no obvious stumbling block. Unfortunately I have so
many things to do and the fact that you keep bitching certainly isn't
a great motivating factor.
--
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: