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~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
