On Sat, Jan 02, 2010 at 07:26:08PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> === added file 'ChangeLog.efiboot'
> --- ChangeLog.efiboot 1970-01-01 00:00:00 +
> +++ ChangeLog.efiboot 2010-01-02 01:48:33 +
> @@ -0,0 +1,19 @@
> +2009-11-28 Vladimir Serbinenko
> +
> + Multib
Hi,
I committed your last patch with some minor stylistic adjustments, plus
your changes to the example kernel.
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gn
Robert Millan wrote:
>
>> 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 decisi
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 onl
On Sun, Jan 3, 2010 at 10:35 AM, Isaac Dupree
wrote:
> Robert Millan wrote:
>>>
>>> In this case color_info is defined as following:
>>
>> I'd appreciate if a native English speaker confirms this, but I believe
>> this should say "as follows" (same for the other instances of this
>> construct).
>
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
Robert Millan wrote:
In this case color_info is defined as following:
I'd appreciate if a native English speaker confirms this, but I believe
this should say "as follows" (same for the other instances of this
construct).
"as follows" reads naturally to me, as a native speaker (also checked:
On Sat, Jan 02, 2010 at 07:26:08PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> 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 us
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
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 d
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 VB
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=0xfff
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=0x
When vbe_control_info is set to 0x all VBE-specific fields are invalid
vbe_mo
13 matches
Mail list logo
