grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Multiboot ammendment: non-VBE video


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [RFC] Multiboot ammendment: non-VBE video
Date: Mon, 28 Dec 2009 13:07:10 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

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
address@hidden 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
address@hidden Function 01h, respectively.
address@hidden Function 01h, respectively. In case of address@hidden video 
driver
address@hidden contains zero and @samp{vbe_mode_info} points
to the
+following 256-byte structure:
+
address@hidden
address@hidden
+        +----------------------+
+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                |
+        +----------------------+
address@hidden group
address@hidden 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 address@hidden video driver
address@hidden 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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]