[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Video mode fixes in linux loader

From: Robert Millan
Subject: Re: [PATCH] Video mode fixes in linux loader
Date: Mon, 13 Apr 2009 20:59:42 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Apr 13, 2009 at 11:16:46AM -0400, Pavel Roskin wrote:
> On Mon, 2009-04-13 at 16:16 +0200, Robert Millan wrote:
> > Please, in general, when you modify code that has been actively worked on
> > by someone, try to get that person involved.
> I tried, but probably not hard enough.  Sorry.

No problem :-)

> > Ok, BUT if we're already in vesa mode, and we know it works (since we're 
> > using
> > it), there's no point in wasting time only to get a worse mode.
> Maybe we should introduce another macro, e.g.
> GRUB_LINUX_VID_MODE_CURRENT, recognize it in the loader and default to
> it.

If we're going to get creative and add new options that weren't present in
the legacy interface, then I'd really prefer if we design a new one, and
better a kernel-independant one like an env variable (we discussed this in
another thread, but didn't agree on which name to use yet).

> Yes, failed loading of one kernel should not affect loading of another
> kernel.  That was the most annoying bug, and I hope it's fixed now.

Yeah I don't see anything wrong with this situation now, but I could be
missing something, since there are many ways to "fail".

> > > Finally, "vga=ask" is now recognized.
> > 
> > With the new loader, Linux' 16-bit entry code is no longer responsible for
> > setting vesa modes, therefore vga=ask can't work.  There's no point in
> > recognizing it (except to warn the user).
> I agree.  Generally, "vga=random_string" causes an error now.  Perhaps
> any unrecognized values of "vga" should cause a warning, not an error.

Probably better when it comes to headless machines, yes...

Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]