From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lt55Q-0002oY-26 for mharc-grub-devel@gnu.org; Sun, 12 Apr 2009 15:11:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lt55O-0002lb-45 for grub-devel@gnu.org; Sun, 12 Apr 2009 15:11:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lt55D-0002g2-0x for grub-devel@gnu.org; Sun, 12 Apr 2009 15:11:17 -0400 Received: from [199.232.76.173] (port=53030 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lt55C-0002ft-Sy for grub-devel@gnu.org; Sun, 12 Apr 2009 15:11:10 -0400 Received: from fg-out-1718.google.com ([72.14.220.155]:46568) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lt55C-0006Sm-Bl for grub-devel@gnu.org; Sun, 12 Apr 2009 15:11:10 -0400 Received: by fg-out-1718.google.com with SMTP id l27so257393fgb.7 for ; Sun, 12 Apr 2009 12:11:09 -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=nlK6QP39W08T34JIXSFNDi7WWSfkHnOVN8aGg/51T/k=; b=Exe1jM8aZLMZF8R7Rit0ADCXIf/cGiIz4cYFkKILKBfatnNlxr0CHP3ERmwFlukT+Z 3M+QwuC3q+FehBA4OrTK4I37ceyIK99dHov4p18Vs2Ss76Dk7wLDYzncBizctlHrC7zu ZhW4axGoRwhaWOVr3QaHqX3dxWZNyJIgZgmy4= 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=MgApEp+sK3NJI/Ai3sz/h9gM73velEdlmmOjDVivrZsXdcfqlkoCdUTK+s+RqhVU+4 dPA4SCykYoXh8POEZojDbzcyc7GhYLEh3rWhNULogdAFcsg5CAVYNguK/JewRQeRTiYV rgeRHwkvDa7dt1uBqsdKPj5rwYiFRn/I2jy0I= Received: by 10.86.89.20 with SMTP id m20mr4233078fgb.8.1239563469271; Sun, 12 Apr 2009 12:11:09 -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 l19sm5736511fgb.16.2009.04.12.12.11.08 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 12:11:08 -0700 (PDT) Message-ID: <49E23CD1.2090106@gmail.com> Date: Sun, 12 Apr 2009 21:11:13 +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> <200904070931.09559.okuji@enbug.org> <1239065374.15621.202.camel@mj> <49DB016D.1070000@gmail.com> <1239141858.6810.15.camel@mj> In-Reply-To: <1239141858.6810.15.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: Sun, 12 Apr 2009 19:11:23 -0000 Pavel Roskin wrote: >> I don't see the code which either handles >> GRUB_LINUX_VID_MODE_ASK or passes it to the kernel. > > We could set params->vid_mode, but the mode setting in the kernel is > done in the 16-bit code that we don't use. Or we could do the actual asking like linux16 does > >> Also it looks like >> vga= parameter is parsed by grub and grub passes only video mode values >> as resolution and color depth. Wouldn't it be better to move to a more >> modern video mode specification method? As gfxpayload variable >> previously discussed on that list > > OK, I just fixed the issue that was annoying me. Being a PC user, I > don't really care about the graphical boot. > > After touching that code, I believe the 32-bit Linux loader should not > parse the vga option at all. It's irrelevant. > This option may be kept for backward compatibility a possible fallback chain is: gfxpayload->vga->previousvideo mode > Instead, the loader should either load the kernel in the current mode > (text of gfxterm) or it should restore the text mode. I believe not all > kernels can start in graphical mode, so using the graphical mode should > be enabled explicitly by some option. > > If the platform doesn't have text mode, then obviously the current mode > should be used. > > I don't see any strong need to use different video modes in GRUB and in > the kernel. If somebody needs that, the mode in GRUB can be changed > before loading the kernel. Also, a kernel video driver can change the > mode upon initialization using driver-specific parameters. > Every OS has its specific needs. E.g. xnu needs to boot in video mode. Perhaps it's just me not knowing how to boot it in text mode but this limitation will have to be respected. And I don't feel like initialising video console just to set a supported mode is a good idea. > GRUB could implement video mode handling compatible with the Linux > internal bootloader, including "vga=ask", but I'm not sure we need it. > I don't think we need it either just no system should be rendered unbootable by this -- Regards Vladimir 'phcoder' Serbinenko