From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NSyoV-0007xQ-Hm for mharc-grub-devel@gnu.org; Thu, 07 Jan 2010 15:18:35 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSyoQ-0007qQ-EZ for grub-devel@gnu.org; Thu, 07 Jan 2010 15:18:30 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSyoN-0007lb-Id for grub-devel@gnu.org; Thu, 07 Jan 2010 15:18:29 -0500 Received: from [199.232.76.173] (port=49575 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSyoM-0007lH-IQ for grub-devel@gnu.org; Thu, 07 Jan 2010 15:18:26 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]:58712) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSyoI-0005UB-V1 for grub-devel@gnu.org; Thu, 07 Jan 2010 15:18:24 -0500 Received: by fg-out-1718.google.com with SMTP id 22so802838fge.12 for ; Thu, 07 Jan 2010 12:18:20 -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=/md85xY9MYclB8axnc7ryQpy2PZ/eP0vvT/Nemc27Hs=; b=NFDewyPDgbpWm4WRDwg+qjUNM3M3cJUMfsjUYJgc9m/RB0AzGC3eGN+ggRPVx/dgcY Alr4JEP7wAyo5DxzpAlCM3D+PotkGYmONl5dguappmna6NYF5uOnZBrAj53NCWh+UGnU 2gFEWKTL/o1p4vE0vn0OiBu5OI/cNeQRFF6/E= 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=XTGi2x6r74JJubBAwwMLIEF9RWs0rAAI6L8lsL7/MutUzZoLR4fWYUb+CZHIOJZJ3Z PaIdEE1Kl160TUernYGi5Vm9vgskrv7l17TtzXu89pCDAsbGbTNiCaJLHw/POYAclmfJ 42MPGmz3FEzwQrywWegwDlG2/ZlDY2E0ptkbI= Received: by 10.86.6.20 with SMTP id 20mr12490319fgf.13.1262895500212; Thu, 07 Jan 2010 12:18:20 -0800 (PST) Received: from debian.bg45.phnet (243-54.79-83.cust.bluewin.ch [83.79.54.243]) by mx.google.com with ESMTPS id e11sm46940584fga.14.2010.01.07.12.18.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 Jan 2010 12:18:16 -0800 (PST) Message-ID: <4B46417F.5050109@gmail.com> Date: Thu, 07 Jan 2010 21:18:07 +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> <4B42430A.5040600@gmail.com> <20100107184545.GA12029@thorin> In-Reply-To: <20100107184545.GA12029@thorin> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5565978C378CA15EE6B5716D" 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: Thu, 07 Jan 2010 20:18:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5565978C378CA15EE6B5716D Content-Type: multipart/mixed; boundary="------------070503010700020300080007" This is a multi-part message in MIME format. --------------070503010700020300080007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Millan wrote: > >> Bootloader will use a mode it >> chooses. Perhaps we should remove recommended mode fields from the spe= c >> altogether or make them somehow optional >> =20 > > Is that important? I'm hesitant to do that untill we have better under= standing > on what lead to this decision. > =20 >>> =20 >>> =20 >> It is useful. It allows payload to say: "I'm ok with video mode but >> prefer text one" >> =20 > > Oh, I think I missunderstood what "EGA-standard text mode" means. Is t= his > the same text mode that survived to this day, and is known in GRUB code= base > as "vga_text"? > > =20 Yes >>> Perhaps it would be simpler for us to arrange it so that flags 11 and= 12 >>> can't be used at the same time. We could just say that flag 11 is re= served >>> and unused, and then put these declarations in the offset that used t= o be for >>> VBE. IIRC there were no possible sections after VBE, so the Framebuf= fer >>> section size wouldn't be constrained by that. >>> >>> But if you prefer to keep flag 11 operational, I don't object. I wou= ld >>> probably object to GRUB implementing it though. >>> >>> =20 >>> =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. >> =20 > > I'd rather encourage them to use modern flag 12 instead. In any case, = it > doesn't to keep flag 11 as part of the standard as long as it's optiona= l. > I'm still not convinced GRUB should implement it, but that's a separate= > discussion. > > =20 Flag 12 doesn't allow to e.g. change the resolution or do the double buffering. >> 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 > > You forgot to attach it. > > =20 Fixed --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------070503010700020300080007 Content-Type: text/x-diff; name="mbvid.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="mbvid.diff" =3D=3D=3D modified file 'doc/multiboot.texi' --- doc/multiboot.texi 2010-01-01 20:02:24 +0000 +++ doc/multiboot.texi 2010-01-04 19:32:13 +0000 @@ -477,9 +477,7 @@ =20 All of the graphics fields are enabled by flag bit 2. They specify the 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. +mode by the OS image. Boot loader may also choose another mode if it see= s fit. =20 The meaning of each is as follows: =20 @@ -488,7 +486,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 @@ -635,6 +635,15 @@ 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 | + +-------------------+ + @end group @end example =20 @@ -911,9 +920,7 @@ @uref{http://www.microsoft.com/hwdev/busbios/amp_12.htm, Advanced Power 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. +If bit 11 in the @samp{flags} is set, the @sc{vbe} table is available. =20 The fields @samp{vbe_control_info} and @samp{vbe_mode_info} contain the physical addresses of @sc{vbe} control information returned by the @@ -935,6 +942,44 @@ Multiboot boot loaders may simulate @sc{vbe} on non-@sc{vbe} modes, as if they were @sc{vbe} modes. =20 +If bit 12 in the @samp{flags} is set, the @sc{Framebuffer} table is avai= lable. + +The field @samp{framebuffer_addr} contains framebuffer physical address.= This field is 64-bit wide but bootloader @dfn{should} set it under 4GiB = if possible for compatibility with payloads which aren't aware of PAE or = amd64. The field @samp{framebuffer_pitch} contains pitch in bytes. The fi= elds @samp{framebuffer_width}, @samp{framebuffer_height} contain framebuf= fer dimensions in pixels. The field @samp{framebuffer_bpp} contains numbe= r of bits per pixel. If @samp{framebuffer_type} is set to 0 it means inde= xed color. In this case color_info is defined as follows: +@example +@group + +----------------------------------+ +110 | framebuffer_palette_addr | +114 | framebuffer_palette_num_colors | + +----------------------------------+ +@end group +@end example +@samp{framebuffer_palette_addr} contains address of palette. Palette is = an array of colour descriptors. Each colour descriptor has following stru= cture: +@example +@group + +-------------+ +0 | red_value | +1 | green_value | +2 | blue_value | + +-------------+ +@end group +@end example +If @samp{framebuffer_type} is set to 1 it means direct RGB color. Then c= olor_type is defined as follows: + +@example +@group + +----------------------------------+ +110 | framebuffer_red_field_position | +111 | framebuffer_red_mask_size | +112 | framebuffer_green_field_position | +113 | framebuffer_green_mask_size | +114 | framebuffer_blue_field_position | +115 | framebuffer_blue_mask_size | + +----------------------------------+ +@end group +@end example + +If @samp{framebuffer_type} is set to 2 it means EGA text. In this case @= samp{framebuffer_width} and @samp{framebuffer_height} are expressed in ch= aracters and not in pixels. @samp{framebuffer_bpp} is equal 16 (16 bits p= er character) and @samp{framebuffer_pitch} is expressed in bytes per text= line. +All further values of @samp{framebuffer_type} are reserved for future ex= pansion =20 @node Examples @chapter Examples --------------070503010700020300080007-- --------------enig5565978C378CA15EE6B5716D 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 iF4EAREKAAYFAktGQYYACgkQNak7dOguQgmbUQD/dF0mFT7VgRlr3QN142VY7+im XTC3TxMGMqgW1tcbtYIA/A8TDveYWNsLeeC7YsnYvUu4KrDtGNGCiOGKtu00Sm+2 =xqq1 -----END PGP SIGNATURE----- --------------enig5565978C378CA15EE6B5716D--