From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NPENk-0004Ca-P1 for mharc-grub-devel@gnu.org; Mon, 28 Dec 2009 07:07:28 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPENi-0004BC-C2 for grub-devel@gnu.org; Mon, 28 Dec 2009 07:07:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPENg-00049i-L4 for grub-devel@gnu.org; Mon, 28 Dec 2009 07:07:25 -0500 Received: from [199.232.76.173] (port=48434 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPENg-00049H-BQ for grub-devel@gnu.org; Mon, 28 Dec 2009 07:07:24 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]:41404) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NPENf-0002UF-TP for grub-devel@gnu.org; Mon, 28 Dec 2009 07:07:24 -0500 Received: by fg-out-1718.google.com with SMTP id 16so16262fgg.12 for ; Mon, 28 Dec 2009 04:07:21 -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=KRUPoUtFBkcopzToD7DcceNe0J6iIcKH+SQI6iKabMA=; b=OQDn7tGLTIC8/av2TU5cyW9pDyKffPZHdOgTQwJhLfzCmyOBp/yqqxvc04O8U5HL6i RN/OMgMu0s+i/z2UhVTLQEZwzP0x2mvtc1+Edax6px+nQkqxsVAMI6CmIKNcZUd1mes6 TVTLDHK8WyHIZKdD7GT+QLCb0UqvauR8X7Jqo= 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=RMJQwkxv6PaBuxxAk34l+6PyOGx6Ee4Ka5ljF0AoDUdXQDt6nou9Xow91xgViSYsR0 rhZ4iZDkUU+6jAFC884+4TuL9u0Rt+Aeu6iDHSNqqt8NzHM/Ro4wv3DMcjCpyADLEK+N exHIzfk+m1e6lgpwb3b9t7qMevOQkwuWI50Bg= Received: by 10.87.76.8 with SMTP id d8mr20207915fgl.66.1262002041730; Mon, 28 Dec 2009 04:07:21 -0800 (PST) Received: from debian.bg45.phnet (17-15.2-85.cust.bluewin.ch [85.2.15.17]) by mx.google.com with ESMTPS id e20sm27284622fga.7.2009.12.28.04.07.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Dec 2009 04:07:19 -0800 (PST) Message-ID: <4B389F6E.70902@gmail.com> Date: Mon, 28 Dec 2009 13:07:10 +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> In-Reply-To: <20091224222923.GW12122@thorin> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig678D3F37CF950110BF95273B" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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: Mon, 28 Dec 2009 12:07:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig678D3F37CF950110BF95273B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Millan wrote: > On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko= wrote: > =20 >> Hello. I'm implementing video part of multiboot specification. >> Currently the only defined interface is for providing VBE info. I >> propose following way to set fields if video is non VBE: >> vbe_control_info=3D0xffffffff >> When vbe_control_info is set to 0xffffffff all VBE-specific fields are= invalid >> vbe_mode set to 0xffff >> vbe_interface_seg=3D0xffff >> vbe_interface_off=3D0xffff >> vbe_interface_len=3D0xff >> vbe_mode_info points to structure similar to vbe_mode_info but with >> all vbe-specific fields set to zero. Remaining (valid) fields are >> (full structur is in include/grub/i386/pc/vbe.h) >> =20 > > This seems like one of these cases in which legacy gets in the way. Wh= y > don't we just replace the legacy structure with something that doesn't = need > dummy fields? > =20 Actually it seems like we already define possible dummy fields if vbe_interface isn't available. vbe_mode_info although contains some vbe callback info and framebuffer information info. We need only second. My idea was that payloads that only use info for framebuffer may be readily working on non-VBE. Alternatively we may define a structure which contains only framebuffer info. This would avoid the requirement to set vbe display line to 0 before calling the payload. The draft I have locally is the following: =3D=3D=3D modified file 'docs/multiboot.texi' --- docs/multiboot.texi 2008-09-03 20:15:15 +0000 +++ docs/multiboot.texi 2009-12-17 20:04:47 +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 loade= r +may also choose another mode if it sees fit. =20 The meaning of each is as follows: =20 @@ -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 this -field contains @samp{0}. +field contains @samp{0}. If video adapter doesn't support EGA text mode = or +bootloader doesn't know how to initialise this mode it may set video +mode even if field contains @samp{1} =20 @item width Contains the number of the columns. This is specified in pixels in a @@ -917,16 +920,62 @@ Management (APM) BIOS Interface Specification}, for more information. =20 If bit 11 in the @samp{flags} is set, the graphics table is available. -This must only be done if the kernel has indicated in the -@samp{Multiboot Header} that it accepts a graphics mode. =20 The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain the physical addresses of @sc{vbe} control information returned by the @sc{vbe} Function 00h and @sc{vbe} mode information returned by the -@sc{vbe} Function 01h, respectively. +@sc{vbe} Function 01h, respectively. In case of non-@sc{vbe} video drive= r +@samp{vbe_control_info} contains zero and @samp{vbe_mode_info} points to the +following 256-byte structure: + +@example +@group + +----------------------+ +0 | flags | +2 | zeros | +16 | pitch | +18 | width | +20 | height | +22 | zeros | +25 | bits per pixel | +26 | zeros | +27 | memory model | +28 | zeros | +31 | red mask size | +32 | red field position | +33 | green mask size | +34 | green field position | +35 | blue mask size | +36 | blue field position | +37 | alpha mask size | +38 | alpha field position | +39 | zero | +40 | framebuffer address | +44 | zero | +50 | pitch | +52 | zero | +54 | red mask size | +55 | red field position | +56 | green mask size | +57 | green field position | +58 | blue mask size | +59 | blue field position | +60 | alpha mask size | +61 | alpha field position | +62 | zeros | + +----------------------+ +@end group +@end example + +All fields have the same meaning as the corresponding VBE mode info +structure except fields marked as zeros which are zero-filled. + +If video is a linear framebuffer boot loader has to ensure that +displayed region starts at offset @samp{0} of linear framebuffer. =20 The field @samp{vbe_mode} indicates current video mode in the format -specified in @sc{vbe} 3.0. +specified in @sc{vbe} 3.0. In case of non-@sc{vbe} video driver +@samp{vbe_mode} contains 0xffff. =20 The rest fields @samp{vbe_interface_seg}, @samp{vbe_interface_off}, and @samp{vbe_interface_len} contain the table of a protected mode interface= --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig678D3F37CF950110BF95273B 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 iF4EAREKAAYFAks4n3UACgkQNak7dOguQgnnUwD9FNKjEEaXjgUBTpBf2Uiva3xR BTZa47jpo6TQQ/+KeBcA/2gyuKZxZShJocA8XxculHs+KVjTVWKWOAvGcKIFgjJ9 =pCZ9 -----END PGP SIGNATURE----- --------------enig678D3F37CF950110BF95273B--