From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LtW70-00038w-OD for mharc-grub-devel@gnu.org; Mon, 13 Apr 2009 20:02:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtW6z-00038H-3v for grub-devel@gnu.org; Mon, 13 Apr 2009 20:02:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtW6u-00035j-IX for grub-devel@gnu.org; Mon, 13 Apr 2009 20:02:48 -0400 Received: from [199.232.76.173] (port=53102 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtW6u-00035b-Fc for grub-devel@gnu.org; Mon, 13 Apr 2009 20:02:44 -0400 Received: from mail-fx0-f166.google.com ([209.85.220.166]:58224) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LtW6t-0006u1-S4 for grub-devel@gnu.org; Mon, 13 Apr 2009 20:02:44 -0400 Received: by fxm10 with SMTP id 10so2439503fxm.42 for ; Mon, 13 Apr 2009 17:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xN8z+DuulhdbaDMSdLUkGn+HwHtaxMGl3hAcyZV2ks4=; b=anENOGRjGY5ujhQ18KaYmJRMMiIC5tgPGKOpICNa0A6gOgVJSmqcpIFEWOlo2nn6bp sKMW7heB5gUuxXPZkuDl1eJjz9n/t1/JBv3roydLo/+Qs8r55kDAeLrGvHdIur9tolWc Cc18aDpQGQxIhk6VOj9Se6Arr2Kjx0SNGpVrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=JthMmEZjVrF3MR4nsXzW1ntSPQp+sX41z7crE1WGqKR3uSIIwS/7z0SB5hgR9wXbRB JNy3YgEwjrYRX4ihbvbZ59V0tSDLiEHnrJbxP9pVkCEZi1PCcWWPMsWN8dG3zNGA3nq7 qNuNyk+bKHciIlbRBFfijxoqKJfHTun//zko8= Received: by 10.86.36.11 with SMTP id j11mr2211770fgj.28.1239667361824; Mon, 13 Apr 2009 17:02:41 -0700 (PDT) Received: from ?192.168.1.25? (116-145.62-81.cust.bluewin.ch [81.62.145.116]) by mx.google.com with ESMTPS id e11sm7710679fga.0.2009.04.13.17.02.41 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 17:02:41 -0700 (PDT) Message-ID: <49E3D2A6.3080503@gmail.com> Date: Tue, 14 Apr 2009 02:02:46 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <1239032043.8986.27.camel@mj> <20090413141657.GE12170@thorin> <20090413144558.GA22165@thorin> <1239637296.3549.9.camel@mj> <20090413190546.GB24072@thorin> <1239664820.13208.50.camel@mj> In-Reply-To: <1239664820.13208.50.camel@mj> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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: Tue, 14 Apr 2009 00:02:49 -0000 Pavel Roskin wrote: > 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. > With proposed autodetections bootloader becomes overzealous. I think it should be configirable but in a more modern way. I think gfxpayload with the same syntax as gfxmode plus additional platform-specific keywords like text80x25 and text80x50 should be fine. If to gfxpayload variable set, then use current mode. I object against a solution of just using current mode because of the current state on EFI: code to retrieve framebuffer address isn't yet used for gfxterm. If this is fixed then I could agree with "last mode" solution. vga= option could be deleted altogether and replaced by warning if someone passes it. If we do so it's better to do before debian switches -- Regards Vladimir 'phcoder' Serbinenko