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

[Robert Millan]

On Mon, Jan 04, 2010 at 08:35:38PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> 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.

Ok then, no big deal.

> 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.

> >>  /* 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

But that's a completely different bit?  I'm a bit confused.

Btw, as you pointed out on IRC, MULTIBOOT_UNSUPPORTED is a GRUB-specific
mask and shouldn't be part of <multiboot.h> anyway.

> >>  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

Sorry, my oversight.  Well it is redundant, not contradictory.  I didn't
express it properly :-)  (some part of my brain doesn't play well with the
rest).

> >>  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"

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"?

> > 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.

> 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.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi