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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
