Robert Millan wrote: > >> Bootloader will use a mode it >> chooses. Perhaps we should remove recommended mode fields from the spec >> altogether or make them somehow optional >> > > Is that important? I'm hesitant to do that untill we have better > understanding > on what lead to this decision. > >>> >>> >> It is useful. It allows payload to say: "I'm ok with video mode but >> prefer text one" >> > > Oh, I think I missunderstood what "EGA-standard text mode" means. Is this > the same text mode that survived to this day, and is known in GRUB codebase > as "vga_text"? > > 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 reserved >>> 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 Framebuffer >>> 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. >>> >>> >>> >> 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. >> > > 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 optional. > I'm still not convinced GRUB should implement it, but that's a separate > discussion. > > 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 >> > > You forgot to attach it. > > Fixed
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
=== 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 @@
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 sees fit.
The meaning of each is as follows:
@@ -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}
@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
@@ -911,9 +920,7 @@
@uref{http://www.microsoft.com/hwdev/busbios/amp_12.htm, Advanced Power
Management (APM) BIOS Interface Specification}, for more information.
-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.
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 n...@sc{vbe} modes, as
if they were @sc{vbe} modes.
+If bit 12 in the @samp{flags} is set, the @sc{Framebuffer} table is available.
+
+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 fields @samp{framebuffer_width}, @samp{framebuffer_height} contain framebuffer dimensions in pixels. The field @samp{framebuffer_bpp} contains number of bits per pixel. If @samp{framebuffer_type} is set to 0 it means indexed 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 structure:
+...@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 color_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 characters and not in pixels. @samp{framebuffer_bpp} is equal 16 (16 bits per character) and @samp{framebuffer_pitch} is expressed in bytes per text line.
+All further values of @samp{framebuffer_type} are reserved for future expansion
@node Examples
@chapter Examples
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
