[Top][All Lists]

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

Re: VBE info request bit per Multiboot Specification 1

From: Robert Millan
Subject: Re: VBE info request bit per Multiboot Specification 1
Date: Fri, 7 Aug 2009 13:14:31 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Aug 04, 2009 at 04:49:57PM -0700, Jan Setje-Eilers wrote:
>  <re-send after fixing subscription>
>> On Tue, Aug 04, 2009 at 01:37:19PM -0400, Francis Shim wrote:
>>> Hi,
>>> In the Multiboot specifications (version 1), there is a flag that
>>> the OS Image can set to request that the boot loader provide VBE
>>> information to the OS kernel upon boot up via the Multiboot
>>> Information structure. Legacy GRUB (GRUB1) deos not support this
>>> feature without a patch that is circulating around in OS
>>> development websites;
>> Hi,
>> It's not implemented.  But since you mention that a patched GRUB  
>> Legacy supports it, I assume there are a number of OSes that
>> implement it.
>  FWIW, we've got a prototype VESA console for Solaris that uses that
> structure to avoid additional mode switches. In fact, was just looking
> into what this looked like in GRUB 2 when someone pointed this thread
> out to me.
>  If the structure is built up compatibly, things should just work.

That's very nice.  I assume it follows the Multiboot spec?  (in theory,
that should suffice, but that's just theory ;-)).

>> Can you provide us with a test case?  This would make an
>> implementation of the GRUB side much easier.
>> Btw, would you like to work on this?  It's not difficult, as we
>> already support something analogous in the Linux loader.
>  Unless there's another preferred interface (or someone beats us to it).
> we'll likely end up filling in. Considering the VBE code that's already
> there this is fairly trivial.

Very well!

Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

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