> I've thinking a little lately about the need for "graphics mode"
> support in the Multiboot standard. In other words, GRUB should do what
> Linux currently can do (set up graphics mode if VESA2 compliant, and
> pass on the linear frame buffer address to the kernel). The reason it
> should be done by GRUB is that it must be done from real mode, and IMO
> a Multiboot kernel shouldn't have to worry about such pesky details of
> the ancient Intel history.. :-)
I think this is an excellent idea.
Thinking ahead to implementation details, I believe we would need the
following:
o a flag bit in the Multiboot header of the kernel to indicate that
it's willing to receive control with the video card in a mode other
than the 'standard' one, and possibly a field to indicate the types
of mode it can deal with (text modes, various organisations of
framebuffer, etc.); this flag bit would be an 'optional feature'
flag
o another flag bit that should be set if the kernel is unwilling to
receive control in the 'standard' mode; this would be a 'required
feature' flag
o some fields in the multiboot_info structure (and a corresponding
flag bit) to indicate the state of the video card; whether it is in
text or graphics mode, where it is in memory, and how it is laid
out
On a related issue, perhaps we could invent some way of indicating to
the kernel what the console should be - at the moment it's system
specific (console= in Linux, etc.). When GRUB can be used over a
serial line, it would be nice for it to be able to tell the operating
system to make that line the console.
Steve Early
