From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LtVS2-0005kc-S7 for mharc-grub-devel@gnu.org; Mon, 13 Apr 2009 19:20:30 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtVS1-0005kT-Qm for grub-devel@gnu.org; Mon, 13 Apr 2009 19:20:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtVRv-0005gJ-Rg for grub-devel@gnu.org; Mon, 13 Apr 2009 19:20:28 -0400 Received: from [199.232.76.173] (port=50508 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtVRv-0005gG-Oa for grub-devel@gnu.org; Mon, 13 Apr 2009 19:20:23 -0400 Received: from c60.cesmail.net ([216.154.195.49]:57317) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1LtVRv-0003Ns-Dn for grub-devel@gnu.org; Mon, 13 Apr 2009 19:20:23 -0400 Received: from unknown (HELO smtprelay2.cesmail.net) ([192.168.1.112]) by c60.cesmail.net with ESMTP; 13 Apr 2009 19:20:22 -0400 Received: from [192.168.0.22] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by smtprelay2.cesmail.net (Postfix) with ESMTPSA id 615CA34C6A for ; Mon, 13 Apr 2009 19:21:54 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20090413190546.GB24072@thorin> References: <1239032043.8986.27.camel@mj> <20090413141657.GE12170@thorin> <20090413144558.GA22165@thorin> <1239637296.3549.9.camel@mj> <20090413190546.GB24072@thorin> Content-Type: text/plain Date: Mon, 13 Apr 2009 19:20:20 -0400 Message-Id: <1239664820.13208.50.camel@mj> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Video mode fixes in linux loader X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 23:20:29 -0000 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