From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [RFC] Multiboot ammendment: non-VBE video
Date: Mon, 28 Dec 2009 13:07:10 +0100 [thread overview]
Message-ID: <4B389F6E.70902@gmail.com> (raw)
In-Reply-To: <20091224222923.GW12122@thorin>
[-- Attachment #1: Type: text/plain, Size: 5247 bytes --]
Robert Millan wrote:
> On Tue, Sep 01, 2009 at 05:37:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> 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=0xffffffff
>> When vbe_control_info is set to 0xffffffff all VBE-specific fields are invalid
>> vbe_mode set to 0xffff
>> vbe_interface_seg=0xffff
>> vbe_interface_off=0xffff
>> vbe_interface_len=0xff
>> 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)
>>
>
> This seems like one of these cases in which legacy gets in the way. Why
> don't we just replace the legacy structure with something that doesn't need
> dummy fields?
>
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:
=== 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 loader
+may also choose another mode if it sees fit.
The meaning of each is as follows:
@@ -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}
@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.
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.
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 driver
+@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.
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.
The rest fields @samp{vbe_interface_seg}, @samp{vbe_interface_off}, and
@samp{vbe_interface_len} contain the table of a protected mode interface
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]
next prev parent reply other threads:[~2009-12-28 12:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 15:37 [RFC] Multiboot ammendment: non-VBE video Vladimir 'phcoder' Serbinenko
2009-12-24 22:29 ` Robert Millan
2009-12-28 12:07 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-01-01 11:30 ` Robert Millan
2010-01-02 18:26 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-03 16:13 ` Robert Millan
2010-01-03 16:35 ` Isaac Dupree
2010-01-04 21:19 ` richardvoigt
2010-01-04 19:35 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-07 18:45 ` Robert Millan
2010-01-07 20:18 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-12 16:52 ` Robert Millan
2010-01-12 16:54 ` Multiboot video in GRUB (Re: [RFC] Multiboot ammendment: non-VBE video) Robert Millan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B389F6E.70902@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.