Robert Millan wrote:
> On Mon, Dec 28, 2009 at 01:07:10PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> 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.
>>     
>
> Yes.  That's the case for vbe_interface_* fields.  But extending this to
> vbe_control_info and vbe_mode_info is backward-incompatible.
>
> I don't object to backward-incompatible changes, but I would expect that
> when we make one, we get the benefit of a clean, legacy-free interface.  In
> this case we carry on with legacy baggage to archieve half-way backward
> compatibility.
>
> In purely practical terms, all of this only has a minimal effect.  GRUB Legacy
> didn't implement these extensions, and GRUB 2 hasn't yet, so use of this
> feature in loadees isn't widespread.  But it has a major impact when it comes
> to reputation.  If we make incompatible changes in the text, we should be
> honest about it.  I don't want people to think they can't rely on Multiboot
> because its maintainers sometimes stretch the definitions in ways not
> permitted by the text.
>
> Since it's obvious we want to change something (rather than implement
> VBE-specific extensions), I propose we start with:
>
> -If bit 11 in the @samp{flags} is set, the graphics table is available.
> +If bit 12 in the @samp{flags} is set, the graphics table is available.
>
> at this point, we can change anything we like.
>
>   
I followed your suggestions. I attach new draft together with drawing of
a blue diagonal line in example kernel (it would be way better to make
it use it for output but it's intended to just show how to use passed
info). I also attach an implementation of multiboot on EFI which uses
this draft. Note that this ammendment is nothing EFI-specific and can be
used with any linear framebuffer driver. The only reason it's in the
same patch is because it was the branch in which I was working on
multiboot improvements and haven't yet splitted individual changes yet

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