All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [RFC] Multiboot ammendment: non-VBE video
Date: Mon, 04 Jan 2010 20:35:38 +0100	[thread overview]
Message-ID: <4B42430A.5040600@gmail.com> (raw)
In-Reply-To: <20100103161352.GA27698@thorin>

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]

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 mode fields from the spec
altogether or make them somehow optional
>>  /* 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
>> === modified file 'doc/multiboot.texi'
>> --- doc/multiboot.texi	2010-01-01 20:02:24 +0000
>> +++ doc/multiboot.texi	2010-01-02 16:58:33 +0000
>> @@ -479,7 +479,8 @@
>>  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
>> @@ -488,7 +489,9 @@
>>  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"
>>  84      | vbe_interface_off |
>>  86      | vbe_interface_len |
>>          +-------------------+
>> +88      | framebuffer_addr  |    (present if flags[12] is set)
>> +96      | framebuffer_pitch |
>> +100     | framebuffer_width |
>> +104     | framebuffer_height|
>> +108     | framebuffer_bpp   |
>> +109     | framebuffer_type  |
>> +110-115 | color_info        |
>>     
>
> 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.
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

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

  parent reply	other threads:[~2010-01-05  4:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01 15:37 [RFC] Multiboot ammendment: non-VBE video Vladimir 'phcoder' Serbinenko
2009-12-24 22:29 ` Robert Millan
2009-12-28 12:07   ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-01 11:30     ` Robert Millan
2010-01-02 18:26       ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-03 16:13         ` Robert Millan
2010-01-03 16:35           ` Isaac Dupree
2010-01-04 21:19             ` richardvoigt
2010-01-04 19:35           ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-01-07 18:45             ` Robert Millan
2010-01-07 20:18               ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-12 16:52                 ` Robert Millan
2010-01-12 16:54         ` Multiboot video in GRUB (Re: [RFC] Multiboot ammendment: non-VBE video) Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B42430A.5040600@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.