From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NS0zm-0004qV-4X for mharc-grub-devel@gnu.org; Mon, 04 Jan 2010 23:26:14 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NS0zj-0004oL-Uk for grub-devel@gnu.org; Mon, 04 Jan 2010 23:26:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NS0ze-0004jD-PV for grub-devel@gnu.org; Mon, 04 Jan 2010 23:26:11 -0500 Received: from [199.232.76.173] (port=52758 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NS0Kj-0006i6-1c for grub-devel@gnu.org; Mon, 04 Jan 2010 22:43:49 -0500 Received: from mx20.gnu.org ([199.232.41.8]:4293) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NRz5K-0002JQ-MP for grub-devel@gnu.org; Mon, 04 Jan 2010 21:23:51 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRsyB-0004QK-0Z for grub-devel@gnu.org; Mon, 04 Jan 2010 14:52:03 -0500 Received: by fg-out-1718.google.com with SMTP id 16so1635640fgg.12 for ; Mon, 04 Jan 2010 11:51:01 -0800 (PST) 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 :x-enigmail-version:content-type; bh=0q6YtxaQvjhdgg5xljyutFkX2VWrYRBHUe6AZPFteIU=; b=NA6fI42K4odFcUIIjdCglCGx8R2HeOndBirmqa4cU/OdxhkJM9oGCIpGRaKEF23RQd o5u2TbeYchr1ycwAU6XZUJzaFBMJ1ihuN+KN56SF/Xl+ZuNoNQiSewxXFlBVNCrm0UFM Q8Kyf+qkydLK+ljE8J+EuS9FZmrm3ZiXX2LBE= 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:x-enigmail-version:content-type; b=Zq+8ZZ2MvafWUzL+IhfAOoVmpAvxaFAXCDOERMnqHxYrte+3gicdfW08TOJmKAmsYl KcQZEZr3fQmHgbcNDb/r2dI5uofMdW4SkFW+V+Fe3rtNHvK7yiQffBeruA9jxcQrsCKQ HpY95cD8o13MEIpaCM7BT9wHR/SzhOU2/rCQo= Received: by 10.87.14.38 with SMTP id r38mr5927344fgi.42.1262634661676; Mon, 04 Jan 2010 11:51:01 -0800 (PST) Received: from debian.bg45.phnet ([81.62.107.61]) by mx.google.com with ESMTPS id e11sm43404582fga.19.2010.01.04.11.50.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Jan 2010 11:50:58 -0800 (PST) Message-ID: <4B42430A.5040600@gmail.com> Date: Mon, 04 Jan 2010 20:35:38 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <20091224222923.GW12122@thorin> <4B389F6E.70902@gmail.com> <20100101113010.GA3692@thorin> <4B3F8FC0.3040004@gmail.com> <20100103161352.GA27698@thorin> In-Reply-To: <20100103161352.GA27698@thorin> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD649F9FD9BD84B916BF3726A" X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [RFC] Multiboot ammendment: non-VBE video X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 04:26:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD649F9FD9BD84B916BF3726A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Millan wrote: > =20 >> + .long 0 >> + .long 1024 >> + .long 768 >> + .long 32 >> =20 > > Maybe better to use 640x480 instead? Not everyone has a large display.= > > =20 It's only a recommended resolution. Bootloader will use a mode it chooses. Perhaps we should remove recommended mode fields from the spec altogether or make them somehow optional >> /* The bits in the required part of flags field we don't support. */= >> -#define MULTIBOOT_UNSUPPORTED 0x0000fffc >> +#define MULTIBOOT_UNSUPPORTED 0x0000fff8 >> =20 > > Shouldn't this be 0xeffc ? (0xfffc & ~0x1000) > > =20 AOUT_KLUDGE field is 0x10000 and not 0x1000 >> =3D=3D=3D modified file 'doc/multiboot.texi' >> --- doc/multiboot.texi 2010-01-01 20:02:24 +0000 >> +++ doc/multiboot.texi 2010-01-02 16:58:33 +0000 >> @@ -479,7 +479,8 @@ >> preferred graphics mode. Note that that is only a @emph{recommended} >> mode by the OS image. If the mode exists, the boot loader should set >> it, when the user doesn't specify a mode explicitly. Otherwise, the >> -boot loader should fall back to a similar mode, if available. >> +boot loader should fall back to a similar mode, if available. Boot lo= ader >> +may also choose another mode if it sees fit. >> =20 > > I agree with changing this, but the phrases seem to contradict each oth= er. If > the mode exists, what should bootloader do? > > I suggest we remove from "If the mode exists..." untill > "...if available", leaving your "Boot loader may also..." only. > > =20 Actually they were contradicting because "should" means that loader may choose not to follow the rule >> @@ -488,7 +489,9 @@ >> Contains @samp{0} for linear graphics mode or @samp{1} for >> EGA-standard text mode. Everything else is reserved for future >> expansion. Note that the boot loader may set a text mode, even if thi= s >> -field contains @samp{0}. >> +field contains @samp{0}. If video adapter doesn't support EGA text mo= de or >> +bootloader doesn't know how to initialise this mode it may set video >> +mode even if field contains @samp{1} >> =20 > > If the EGA option is obsolete/useless, I'd just make it: > > Reserved for backward compatibility. Always contains @samp{0}. > > and schedule it for removal in next major version. > > =20 It is useful. It allows payload to say: "I'm ok with video mode but prefer text one" >> 84 | vbe_interface_off | >> 86 | vbe_interface_len | >> +-------------------+ >> +88 | framebuffer_addr | (present if flags[12] is set) >> +96 | framebuffer_pitch | >> +100 | framebuffer_width | >> +104 | framebuffer_height| >> +108 | framebuffer_bpp | >> +109 | framebuffer_type | >> +110-115 | color_info | >> =20 > > Perhaps it would be simpler for us to arrange it so that flags 11 and 1= 2 > can't be used at the same time. We could just say that flag 11 is rese= rved > and unused, and then put these declarations in the offset that used to = be for > VBE. IIRC there were no possible sections after VBE, so the Framebuffe= r > section size wouldn't be constrained by that. > > But if you prefer to keep flag 11 operational, I don't object. I would= > probably object to GRUB implementing it though. > > =20 If payload wants to use VBE it will. I think that providing this informtion saves payload a trip to real mode. So this way we encourage saner real-mode-free OS design. Do you think it would be useful to make flag 12 structure describe EGA text too? I attach new diff for multiboot.texi. If it's approved it should be simple to implement in grub2 and example kernel --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigD649F9FD9BD84B916BF3726A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAktCQxAACgkQNak7dOguQgmpOAD/U+Ep1yIsZlKrk/ZvdRF1gHoo lmnjONwPFooIV/vxE38BAItPlNMWig0kBXxBZcY3uPOm3B8M2/MhkJIv84NV0+Cz =5tfK -----END PGP SIGNATURE----- --------------enigD649F9FD9BD84B916BF3726A--