On Mon, 2009-04-13 at 21:05 +0200, Robert Millan wrote: > On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote: > > I actually installed GRUB with gfxterm on a laptop that has Intel > > framebuffer support. Now the kernel starts in VESA mode and then the > > screen goes blank because intelfb cannot deal with it. Sure, intelfb > > should be fixed, but we should be liberal in what we accept. > > We could detect this situation by checking video= parameter, and setting > text mode if intelfb is found. But then again do we want to prevent > future versions of intelfb from gracefuly transitioning from vesa mode > without screen glitch?
No, that would be bad. It's even possible that intelfb would work correctly in other configurations. The laptop has resolution 1440x900 that doesn't match any VESA mode. > > Some > > kernels may not support VESA modes at all. > > I don't think this is applicable; all modern versions of Linux include > vesa modesetting in its 16-bit entry code, and older versions are already > detected by the new loader (user is prompted to use linux16). I can disable CONFIG_FB, and then the screen remains blank until X starts. It's entirely possible that some distros don't enable CONFIG_FB to save memory, and I don't always enable it in the kernels I configure myself. > > Adding vga=0 to the kernel command line didn't fix it. That's bad. > > "vga=0" means text mode 80x25. Adding "vga=1" fixed the problem. The > > text mode was 80x25, not 80x50, so that's another issue. > > Shouldn't be hard to fix. Do you know how to switch to 80x50 mode? Well, load 8x8 font. It's done in the 16-bit code. > > "vga=ask" is not a warning now. It causes "error: You need to load the > > kernel first", apparently from initrd. In other words, the "linux" > > command fails and there is no visible warning. > > Sounds like my error code is wrong, but we could turn it into a warning > like you suggested. I was editing the command line from the menu, so I could not see the message. Waiting for input is a fair game for an option that implies waiting for input. -- Regards, Pavel Roskin _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
