From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MaXaH-0005S2-8B for mharc-grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaXaF-0005Rt-RA for grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaXaA-0005Px-Ae for grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:50 -0400 Received: from [199.232.76.173] (port=56569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaXaA-0005Pu-4d for grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:46 -0400 Received: from mx20.gnu.org ([199.232.41.8]:58633) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MaXa8-0000hj-Qu for grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:45 -0400 Received: from smarthost01.mail.zen.net.uk ([212.23.3.140]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MaXa7-0000fu-Th for grub-devel@gnu.org; Mon, 10 Aug 2009 12:18:44 -0400 Received: from [82.69.40.219] (helo=riva.pelham.vpn.ucam.org) by smarthost01.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1MaXa6-0002cQ-Pe for grub-devel@gnu.org; Mon, 10 Aug 2009 16:18:42 +0000 Received: from cjwatson by riva.pelham.vpn.ucam.org with local (Exim 3.36 #1 (Debian)) for grub-devel@gnu.org id 1MaXa6-0004YB-00; Mon, 10 Aug 2009 17:18:42 +0100 Date: Mon, 10 Aug 2009 17:18:42 +0100 From: Colin Watson To: The development of GRUB 2 Message-ID: <20090810161841.GB11691@riva.ucam.org> References: <20090810110102.GP11691@riva.ucam.org> <20090810152725.GC11134@thorin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090810152725.GC11134@thorin> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-Smarthost01-IP: [82.69.40.219] X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Improve handling of "keep" in gfxpayload 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, 10 Aug 2009 16:18:52 -0000 On Mon, Aug 10, 2009 at 05:27:25PM +0200, Robert Millan wrote: > On Mon, Aug 10, 2009 at 02:05:15PM +0200, Vladimir 'phcoder' Serbinenko wrote: > > What is the linux behaviour with 0x0F04? Does it just keep the mode? > > What if the same mode is passed as a value? Does linux redoes the > > modesetting? If 0x0F04 works ok I would prefer to always pass it when > > kernel is booted in graphical mode. VESA mode numbers are an artifact > > and when grub2 has its own graphical drivers it won't correspond to > > anything. > > I might be missing something, but AFAICT VESA mode numbers are only passed > by the user in the "vga=" option. > > There's also the `vid_mode' parameter in Linux header, but it's only used by > legacy code, and with the 32-bit boot protocol Linux doesn't read it. Hmm. You seem to be right, on investigation (I'd missed the fact that the 32-bit boot protocol skips a whole bunch of initialisation code), but in that case I'm thoroughly confused about why setting it made any difference at all in my tests. Back to the drawing board, I guess. (It's not actually quite true that vid_mode isn't used *at all* with the 32-bit boot protocol; it's still saved for use with ACPI sleep.) > Does 0x0F04 really do something when used in combination with Linux' vesafb? It seems to be 16-bit boot protocol only. I withdraw this patch for the time being as I'm obviously confused. -- Colin Watson [cjwatson@ubuntu.com]