Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Ian Jackson writes (Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console): I think all that's going to be said has been said. So I hereby propose the following resolution and immediately call for a vote. Thanks everyone for your contributions, and thanks to the voting committee members for your votes. The following resolution has passed: 1. The Technical Committee has considered the question of whether VESA fb support should be compiled into the default kernel, as requested in Bug#161931. 2. We have concluded that: * inclusion has significant benefits for some users, and * inclusion has no significant costs. Therefore, the VESA fb driver should be included. 3. In particular, we have considered the following supposed downsides to including the driver in the distribution kernel: a. That the increase in kernel size (while not significant for just VESA fb) due to including all other non-modular drivers in a similar position, would be significant and perhaps problematic for boot floppies etc. This question is difficult to analyse conclusively, but we feel it is largely unsubstantiated. If demand for many other similar drivers turns out to be similarly high, and including them is a problem, we are certainly prepared to make specific decisions in specific cases, and/or revisit VESA fb as part of a broader question. b. That the non-modularity of the VESA driver harms the kernel architecture. This is clearly relevant for a kernel architect, when choosing what drivers to include in a source tree. However, we do not feel that it is relevant when - as distributors - we consider which drivers to enable or disable. 4. Accordingly we request (or require, if the required supermajority is reached according to the Constitution) that the Debian kernel maintainers change the configuration to include the VESA fb driver in the default kernel, at their earliest convenience. Votes in favour: Ian, Jason, Raul. Votes against: Manoj. We have achieved the 3:1 majority required to overrule the maintainer. I'll re-reassign the bug, and update the committee web page. Ian.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Jason Gunthorpe [EMAIL PROTECTED] wrote:
This explains the very strong technical reason why vesafb and fbcon have
to be compiled in statically. Basically, the VESA spec defines a set of
real mode BIOS calls to do mode switching and interrogate some information
about the new video mode. These must be executed in real mode, and the
only time the kernel is running in real mode is in the earliest stages of
boot.
The calls cannot be made _ever_ once the kernel has been booted unless you
resort to such trickery as using a BIOS emulator like Gerg alluded too.
The kernel simply has no mechanism for calling real mode x86 BIOS code.
The fact that the mode switching has to be compiled in statically does
not preclude the modularisation of vesafb since it is already a separate
piece of code goverened by a different CONFIG option.
Herbert mentioned this:
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.
Which I do not belive is correct. Once the VESA call has been made to
switch the framebuffer from cell mode (ie text mode) to bitmap mode the
normal text console driver will stop working completely. If the kernel
does not immediately boot and begin using vesafb+fbcon it will no longer
be able to display anything.
If VESAFB is modularised, then you would load it from the initrd just
like any other essential module. In fact, in future it may become
the modus operandi with the advent of early user space.
As a proof that this already works, just look at how TGAFB is loaded on
alpha. It is completely analogous to this situation except that the
video mode switching is already done.
VESAFB will also be unique in this case, so the slippery slope Herbert is
afraid of can easially be stopped by recognizing that it truely is a
special driver.
Console drivers per se probably aren't that bad. Although even there,
VESAFB is certainly not unique. The other non-modularised console
drivers include the serial console, as well as the parallel console.
The former is currently included while the latter isn't.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
#include hallo.h * Herbert Xu [Sun, Nov 03 2002, 10:29:54PM]: The calls cannot be made _ever_ once the kernel has been booted unless you resort to such trickery as using a BIOS emulator like Gerg alluded too. The kernel simply has no mechanism for calling real mode x86 BIOS code. The fact that the mode switching has to be compiled in statically does not preclude the modularisation of vesafb since it is already a separate piece of code goverened by a different CONFIG option. Well, could you explain the connection between a config option and the actuall feasibility? Which I do not belive is correct. Once the VESA call has been made to switch the framebuffer from cell mode (ie text mode) to bitmap mode the normal text console driver will stop working completely. If the kernel does not immediately boot and begin using vesafb+fbcon it will no longer be able to display anything. If VESAFB is modularised, then you would load it from the initrd just s/If/When/, that is the question. I do not see anybody working on modularizing it, do you? From my point of view, the things are clear: No kernel developer really needs it or has too much spare time to work on modularisation of VESAFB. The driver is so small that there is no problem including it into the kernel. We can either wait for a wonder that will never happen, or you can rewrite the driver by yourself, or admit that including it is not that bad and just do it. As a proof that this already works, just look at how TGAFB is loaded on alpha. It is completely analogous to this situation except that the video mode switching is already done. Really? I do not know about compatibility modes on Alpha such as the sick oldcompatible real mode on i386. Gruss/Regards, Eduard. -- Debian: All the power, no red hats, no green chameleons.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Raul Miller writes (Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console): [details of proposal elided] I think this proposal matches the best information we have available and I vote for this proposal. So, would everyone else please vote ? If you don't have an opinion or don't want to vote, please explicitly abstain. That will shorten the voting period due to the `no longer in doubt' rule. I didn't say so earlier, but obviously I vote in favour of my proposal too. Here's another copy, in case you missed it: 1. The Technical Committee has considered the question of whether VESA fb support should be compiled into the default kernel, as requested in Bug#161931. 2. We have concluded that: * inclusion has significant benefits for some users, and * inclusion has no significant costs. Therefore, the VESA fb driver should be included. 3. In particular, we have considered the following supposed downsides to including the driver in the distribution kernel: a. That the increase in kernel size (while not significant for just VESA fb) due to including all other non-modular drivers in a similar position, would be significant and perhaps problematic for boot floppies etc. This question is difficult to analyse conclusively, but we feel it is largely unsubstantiated. If demand for many other similar drivers turns out to be similarly high, and including them is a problem, we are certainly prepared to make specific decisions in specific cases, and/or revisit VESA fb as part of a broader question. b. That the non-modularity of the VESA driver harms the kernel architecture. This is clearly relevant for a kernel architect, when choosing what drivers to include in a source tree. However, we do not feel that it is relevant when - as distributors - we consider which drivers to enable or disable. 4. Accordingly we request (or require, if the required supermajority is reached according to the Constitution) that the Debian kernel maintainers change the configuration to include the VESA fb driver in the default kernel, at their earliest convenience. Ian.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
On Sat, 2 Nov 2002, Ian Jackson wrote: So, would everyone else please vote ? If you don't have an opinion or don't want to vote, please explicitly abstain. That will shorten the voting period due to the `no longer in doubt' rule. I agree with Ian's assement. So count this as a 'yes' vote. Sorry I didn't have time to speak up during the discussion, but since I've worked with the VESA calls and x86 VGA hardware quite abit in the distant past let me chime in about the non-modularity bit.. Eduard had this in email from from the VESA FB author: No. vesafb depends on the VGA BIOS activating the graphics mode (which is done in real mode startup code). Thus it works on nearly all graphics cards on earth, but it also has a few drawbacks: Limited to flickering 60Hz standard vesa modes, no mode switching at runtime, it's very slow, ... This explains the very strong technical reason why vesafb and fbcon have to be compiled in statically. Basically, the VESA spec defines a set of real mode BIOS calls to do mode switching and interrogate some information about the new video mode. These must be executed in real mode, and the only time the kernel is running in real mode is in the earliest stages of boot. The calls cannot be made _ever_ once the kernel has been booted unless you resort to such trickery as using a BIOS emulator like Gerg alluded too. The kernel simply has no mechanism for calling real mode x86 BIOS code. Herbert mentioned this: 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. Which I do not belive is correct. Once the VESA call has been made to switch the framebuffer from cell mode (ie text mode) to bitmap mode the normal text console driver will stop working completely. If the kernel does not immediately boot and begin using vesafb+fbcon it will no longer be able to display anything. VESAFB will also be unique in this case, so the slippery slope Herbert is afraid of can easially be stopped by recognizing that it truely is a special driver. Jason
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Hi, I would like to add the dissenting opinion: Though I personally would probably include vesafb and fbcron in the kernel, I don't think I have heard strong enough arguments to justify overriding the maintainers judgment: a) Not every possible modules is included in even our modular kernels; people have to compile custom kernels for various hardware components b) Not all file systems are compiled into the kernel c) I do not see why vesafb users are special, and root on JFS people are not; why the former can't compile their own kerels, the latter must. d) Most users douse X, e) people can also use text consoles if they do not use X. I have not seen compelling arguments why one things vesa users are special, or indeed, numerous; not enough to convince me to substitute my own judgment over the person responsible for the package, and who does all the work for maintaining it. Historically, the debian developer has been allowed a fair degree of autonomy over their package; this is not really a technical problem, really, it is a judgment call; and I think we should strive not to override a developer unless we have more than gut feelings and opinions. For this reason, I hereby vote against the proposal. manoj -- In the same way that a wrongly handled blade of grass will cut one's hand, so a badly fulfilled life in religion will drag one down to hell. 311 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpLZ3YlpbeAC.pgp Description: PGP signature
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Raul Miller writes (Re: [EMAIL PROTECTED]: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]): On Sun, Oct 27, 2002 at 01:37:43PM -0600, Manoj Srivastava wrote: What I am unsure about is whether I have the grounds to cause my judgment to override the maintainers in this case. I don't have the hubris to assume that I know so much better than the maintainer. I think we can trust the developer to explain his reasons. We're not expected to be omniscient. Herbert has already said that he'd go along with our decision. And, from the way the discussion has gone, I trust that means that he's already said everything he has to say on the subject. I agree, and I'm just about to write up a draft resolution. Ian.
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
I think all that's going to be said has been said. So I hereby propose the following resolution and immediately call for a vote. 1. The Technical Committee has considered the question of whether VESA fb support should be compiled into the default kernel, as requested in Bug#161931. 2. We have concluded that: * inclusion has significant benefits for some users, and * inclusion has no significant costs. Therefore, the VESA fb driver should be included. 3. In particular, we have considered the following supposed downsides to including the driver in the distribution kernel: a. That the increase in kernel size (while not significant for just VESA fb) due to including all other non-modular drivers in a similar position, would be significant and perhaps problematic for boot floppies etc. This question is difficult to analyse conclusively, but we feel it is largely unsubstantiated. If demand for many other similar drivers turns out to be similarly high, and including them is a problem, we are certainly prepared to make specific decisions in specific cases, and/or revisit VESA fb as part of a broader question. b. That the non-modularity of the VESA driver harms the kernel architecture. This is clearly relevant for a kernel architect, when choosing what drivers to include in a source tree. However, we do not feel that it is relevant when - as distributors - we consider which drivers to enable or disable. 4. Accordingly we request (or require, if the required supermajority is reached according to the Constitution) that the Debian kernel maintainers change the configuration to include the VESA fb driver in the default kernel, at their earliest convenience. Ian.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Hi, All right. If we are embarking on the path of substituting the maintainers judgment by our own, I personally would include both vesafb and fbcon as builtin, and address the other non modular drivers as and when I feel the demand for them has increased to the point that including them is justified. Unfortunately, this is a matter of exercising judgment, and I do not have solid reasoning or datas to back up my gut feelings. What I am unsure about is whether I have the grounds to cause my judgment to override the maintainers in this case. I don't have the hubris to assume that I know so much better than the maintainer. manoj -- I figured there was this holocaust, right, and the only ones left alive were Donna Reed, Ozzie and Harriet, and the Cleavers. Wil Wheaton explains why everyone in Star Trek: The Next Generation is so nice Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
On Sun, Oct 27, 2002 at 01:37:43PM -0600, Manoj Srivastava wrote: What I am unsure about is whether I have the grounds to cause my judgment to override the maintainers in this case. I don't have the hubris to assume that I know so much better than the maintainer. I think we can trust the developer to explain his reasons. We're not expected to be omniscient. Herbert has already said that he'd go along with our decision. And, from the way the discussion has gone, I trust that means that he's already said everything he has to say on the subject. Thanks, -- Raul
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
#include hallo.h * Manoj Srivastava [Sat, Oct 26 2002, 12:10:06AM]: Maintainability? There is more to clean code than mere aesthetics. As the kernel moves towards initrds and modularity, crufty Yes, you and Xu are of the same kind. You place some ideals (code perfectness, even with harmless code) over user's wishes. Ian Guesswork. No-one in this argument has any concrete data. Yes. But the mainainer, being close to the package, and presumably interacting with more users than non maintainers, often has a better feel for subjective guess work like this. Exactly this is the question and the answer (here) is: NO. Ian Do business users often turn on quotas on desktop machines ? I'd be Ian surprised. For servers, of course, most people will (or should!) Ian build their own kernels. Then I think you should be prepared to be surprised; Dec/Compaq, the university of massachusetts at amherst (various departments), and several other companies I a=have ahd contact with all had soft and hard quotas turned on. Well, on how machines? Sure they should be enabled on large servers, the number of them is not impressive. The maintainer has come up with a reasonable stance that the solution requires suboptimal code; prevents inclusion of modular code that other users may like, there is a reasonable alternative (vga16), and in his considered judgement fulfillment of the wishlist is bad. When the maintainer does not give much on the user's wishes if they do not match their own's, I will fight against this rule (*). I showed that vga16 is an excuse and not a replacement. (*): A fresh case, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=121335repeatmerged=yes Prety easy to fix in the kernel and it would work for any program. But how refuses to accept this simple fix, because of the same only-my-upstream-code-as-modules-is-perfect-dogma? The ctte has no grounds to override the maintainer based on mere guesswork, since they can't in honesty claim to have better guesses than the maintainer. Reminds me on the Ivanova's God speech, but those days it was funny(**). Gruss/Regards, Eduard. PS: (**) On your way back I'd like you to memorize the Babylon 5 mantra. Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recommendations. Ivanova is god. And, if this ever happens again, Ivanova will personally rip your lungs out. Babylon control out.
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
On Sat, Oct 26, 2002 at 09:34:47AM +0200, Eduard Bloch wrote: Yes, you and Xu are of the same kind. You place some ideals (code perfectness, even with harmless code) over user's wishes. Please, Eduard, this discussion is not about the people involved, it's about the technical merits of vesa fb vs. no vesa fb. -- Raul
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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, 10:00:20PM]: 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. Exactly, you argument with minority not knowing the numbers. 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. Useable - sure, but how? Sticked to 640x480, too large font, a nightmare for console user. And it is not sharpen on LCD monitors while you can set a vesafb resolution that you need. 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, ... As said, _good_ examples. How many users need that features? Note, am talking about masses of home and soho systems, not terminal servers. 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. I do not know any single user that uses quota on the personal box, only few servers. 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. As said, WHO needs it? 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. Sure. But I am not the first and not the last person bitching about your bullheaded decisions. EOD. Gruss/Regards, Eduard. -- weasel for i in *; do if ( cat $i | grep -q hallo ); then echo $i; fi; done [einen Tag später] -:- Topic (#debian.de): changed by _shorty_: Award fuer useless use of cat an Weasel verliehen. :)
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Herbert Xu writes (Re: [EMAIL PROTECTED]: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]): ... Who is supposed to make these decisions about how many people are interested? Should I ask you every time this comes up? If you end up getting into a serious enough dispute about it, yes. That's what we're here for. To sum up I'm rather worried if the basis of your decision is purely on the fact that you are satisfied that enough people are interested in VESA fb. It seems to me that the question is precisely whether enough people are interested in VESA fb. Ian.
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 11:11:42PM +0100, Ian Jackson wrote:
Herbert Xu writes (Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]):
...
Who is supposed to make these decisions about how many people are
interested? Should I ask you every time this comes up?
If you end up getting into a serious enough dispute about it, yes.
That's what we're here for.
OK, in that case I shall await your decision and implement it
accordingly.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
