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
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
>
> Well, I think this is where we disagree. I don't think having a kernel
> without a console till initrd is a good idea. I understand it's
> technically possible, but, doesn't seem like something the standard kernel
> should be doing.
>From all the in
On Sun, 3 Nov 2002, Herbert Xu wrote:
> Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> 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.
Well, I think
#include
* 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 fac
On Sun, Nov 03, 2002 at 10:29:54PM +1100, Herbert Xu wrote:
> 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.
[1] I think that the alpha hardware is less variable
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.
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
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 do
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
On Wed, Oct 30, 2002 at 10:39:38PM +, Ian Jackson wrote:
> 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.
[details of proposal elided]
I think this proposal matches the best information we have available
and
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.
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 ov
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 trus
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 th
On Sat, Oct 26, 2002 at 10:01:44PM +0100, Ian Jackson wrote:
> No, Raul is not making that assumption. He's just pointing out that
> the decisions about kernel architecture need different considerations
> to the decisions about what to ship in a distribution.
Exactly.
> The alleged cost of the n
>>">>>" == Ian Jackson <[EMAIL PROTECTED]> writes:
>>>> Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
>>>> kernel-image-2.4.19-k7: VESA driver for console]"):
>> [Raul:]
>> > I made an earlie
Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
> [Raul:]
> > I made an earlier comment on that discussion thread:
> > "This is an argument for the kernel architects. We're not kernel
>>">" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Perhaps I've missed something?
>> On Sat, Oct 26, 2002 at 10:20:59AM -0500, Manoj Srivastava wrote:
>> Did you get Herberts mail detailing his objections to the
>> inclusion of vesafb?
>> I made an earlier comment on that discussion thre
> Raul> Perhaps I've missed something?
On Sat, Oct 26, 2002 at 10:20:59AM -0500, Manoj Srivastava wrote:
> Did you get Herberts mail detailing his objections to the
> inclusion of vesafb?
I made an earlier comment on that discussion thread:
"This is an argument for the kernel architect
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> On Sat, Oct 26, 2002 at 12:10:06AM -0500, Manoj Srivastava wrote:
>> 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.
Raul>
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
On Sat, Oct 26, 2002 at 12:10:06AM -0500, Manoj Srivastava wrote:
> 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.
Correct.
Instead we need to judge based on available evidence.
#include
* 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 harmle
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Well, certainly it's not decisive, but we're unlikely to get better
Ian> information. We're going to have to decide on the basis of the
Ian> information we have available, I think.
Then I do not think we have enough data to overr
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
> > interest
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 seriou
On Fri, Oct 25, 2002 at 07:49:56PM +0100, Ian Jackson wrote:
> So let me see if I can summarise what the pros and cons are, that have
> been mentioned so far:
>
> Pro:
>
> * Some laptop users and certain others who wish to use the console
>in better video modes have an easier life, as they c
> >>">>" == Ian Jackson <[EMAIL PROTECTED]> writes:
> >> * Some laptop users and certain others who wish to use the console
> >>in better video modes have an easier life, as they can do so with
> >>the stock Debian kernel. How many people would benefit seems to be
> >>disputed, bu
Manoj Srivastava writes ("Re: [EMAIL PROTECTED]: Re: Bug#161931:
kernel-image-2.4.19-k7: VESA driver for console]"):
> I am not sure the latter follows. Certainly, there is a (small)
> vocal set of users, but popularity is still in question.
Well, certainly it's no
>>">>" == Ian Jackson <[EMAIL PROTECTED]> writes:
>> So let me see if I can summarise what the pros and cons are, that have
>> been mentioned so far:
>> Pro:
>> * Some laptop users and certain others who wish to use the console
>>in better video modes have an easier life, as they can d
So let me see if I can summarise what the pros and cons are, that have
been mentioned so far:
Pro:
* Some laptop users and certain others who wish to use the console
in better video modes have an easier life, as they can do so with
the stock Debian kernel. How many people would benefit se
#include
* 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 att
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 attitu
#include
* Herbert Xu [Fri, Oct 25 2002, 06:50:08PM]:
> 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
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.
> E
>>"Eduard" == Eduard Bloch <[EMAIL PROTECTED]> writes:
>> include
Eduard> * Raul Miller [Wed, Oct 23 2002, 05:59:42PM]:
>> > That would be a good start.
>>
>> Ok. Next question: who poses the questions? [I'll do it if no one
>> else does: sometime tomorrow. If you prefer your own styl
#include
* Raul Miller [Wed, Oct 23 2002, 05:59:42PM]:
> > That would be a good start.
>
> Ok. Next question: who poses the questions? [I'll do it if no one
> else does: sometime tomorrow. If you prefer your own style of asking
Wait, I found the answer from Gerd from our last conversation
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> On the other hand, I feel this committee needs concrete proposals to
Raul> discuss. If we don't have anything concrete: accepting, rejecting and
Raul> modifying nonexistant proposals is rather difficult.
If we can get a definit
On Wed, Oct 23, 2002 at 11:45:36AM -0500, Manoj Srivastava wrote:
> Raul> Perhaps we should invite Herbert Xu and/or Gerd Knorr to
> Raul> comment on this subject?
>
> That would be a good start.
Ok. Next question: who poses the questions? [I'll do it if no one
else does: sometime tomo
[EMAIL PROTECTED] (Raul Miller) writes:
> What do the rest of you think?
It would help to know what evidence, anecdotal or otherwise, Herbert has for
feeling the vesafb stuff doesn't work on some machines. I personally haven't
heard that, but that says nothing.
I'm generally inclined to side w
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Proposal 1: we believe Herbert Xu and agree that vesa support not be
Raul> included in debian kernels.
Raul> Proposal 2: we believe that vesa support is both useful and harmless
Raul> and ask Herbert Xu to include it in debian kernels.
On Wed, Oct 23, 2002 at 11:26:52AM +0200, Eduard Bloch wrote:
> See below. I claim Herbert Xu to decide not reasonable in this issue,
> working against ?4 of the social contract. Please decide wise and force
> him to change the current situation.
>
> See also
>
> http://bugs.debian.org/cgi-bin/bug
t, 5 Oct 2002 22:14:58 +1000
From: Herbert Xu <[EMAIL PROTECTED]>
Subject: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
reassign 161931 kernel
merge 104101 161931
quit
On Sat, Oct 05, 2002 at 01:27:50PM +0200, Eduard Bloch wrote:
43 matches
Mail list logo
