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