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

[Vladimir 'φ-coder/phcoder' Serbinenko]

Robert Millan wrote:
>   
>> +    .long 0
>> +    .long 1024
>> +    .long 768
>> +    .long 32
>>     
>
> Maybe better to use 640x480 instead?  Not everyone has a large display.
>
>   
It's only a recommended resolution. Bootloader will use a mode it
chooses. Perhaps we should remove recommended mode fields from the spec
altogether or make them somehow optional
>>  /* The bits in the required part of flags field we don't support.  */
>> -#define MULTIBOOT_UNSUPPORTED                       0x0000fffc
>> +#define MULTIBOOT_UNSUPPORTED                   0x0000fff8
>>     
>
> Shouldn't this be 0xeffc ?  (0xfffc & ~0x1000)
>
>   
AOUT_KLUDGE field is 0x10000 and not 0x1000
>> === modified file 'doc/multiboot.texi'
>> --- doc/multiboot.texi       2010-01-01 20:02:24 +0000
>> +++ doc/multiboot.texi       2010-01-02 16:58:33 +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.
>>     
>
> I agree with changing this, but the phrases seem to contradict each other.  If
> the mode exists, what should bootloader do?
>
> I suggest we remove from "If the mode exists..." untill
> "...if available", leaving your "Boot loader may also..." only.
>
>   
Actually they were contradicting because "should" means that loader may
choose not to follow the rule
>> @@ -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}
>>     
>
> If the EGA option is obsolete/useless, I'd just make it:
>
>   Reserved for backward compatibility.  Always contains @samp{0}.
>
> and schedule it for removal in next major version.
>
>   
It is useful. It allows payload to say: "I'm ok with video mode but
prefer text one"
>>  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        |
>>     
>
> 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.
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

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature