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