Re: Multiboot2 Suggestions

[Vladimir 'φ-coder/phcoder' Serbinenko]

Brendan Trotter wrote:
>>> I currently use "PC speaker" as my "critical error notification
>>> method" - it's about 15 instructions that use I/O ports only and
>>> doesn't require memory allocations or anything else. I doubt setting
>>> keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
>>> anything more than I/O ports.
>>>
>>> In comparison, my video setup code is around 64 KiB of code that
>>> starts with trying to get EDID information from the monitor, filtering
>>> a list of video modes (from VGA and/or VBE), allocating several MiB of
>>> RAM for video buffers and font data, scaling font data, etc. If
>>> there's a problem setting up the memory management it's all useless
>>> and I fall back to the "critical error notification method" so the
>>> user knows the OS failed to initialise something (e.g. couldn't
>>> allocate several MiB of RAM).
>>>
>>>       
>> If you use frmaebuffer info in mbi you can have basic video much faster.
>>     
>
> I'm not planning to have any support for "basic video" (only "eye
> candy video"). I don't support text modes either (and have no desire
> to add support for text modes).
>
> I'm also wondering if a "primary monitor's EDID" tag could be added to
> the multi-boot information. This tag would optional - if the boot
> loader can't get the information, or if the boot loader doesn't even
> try to get the information, then the boot loader can skip the EDID tag
> (but the EDID information is easy to obtain from VBE and U/EFI if
> you're writing "firmware specific" code).
>
> Where possible, I currently use the EDID information to determine the
> physical size of the monitor (e.g. "520 mm wide and 320 mm high"), and
> then scale font data, etc to suit; so that everything is the same
> shape regardless of the monitor's aspect ratio, so that things aren't
> too small on a small screen or too big on a large screen, and so that
> everything looks the same in all video modes (resolution independent).
> For an example, for a 1600*1200 video mode on a small 4:3 monitor I
> might end up with 32*42 characters, for a 800*600 video mode on the
> same small 4:3 monitor I might end up with 16*21 characters, and for a
> 800*600 video mode on a large 16:9 monitor I might end up with 8*19
> characters; and in all of these cases I can draw a square box (that
> doesn't look like a rectangle in any case).
>
>   
Perhaps it's better to just supply estimated DPI?
>>> Alternatively, (for my OS) for headless systems; I use RTS/CTS and the
>>> VT100 "identify" command to detect if anything is listening on the
>>> serial port (and if it's a terminal or something else). When nothing
>>> is listening on the other end the OS can't talk so it uses the PC
>>> speaker as a fallback (but continues monitoring the serial port).
>>> Basically if something goes wrong at any stage, the OS beeps, and the
>>> user can plug a terminal in afterwards to find out what went wrong
>>> (rather than having no idea what caused the problem, then connecting a
>>> terminal and rebooting to see if it happens again while they are
>>> watching).
>>>
>>>       
>> I feel like here it's not anymore about present hardware or its state
>> but about user configuration. Generally for this type of parameters
>> command line is better suited.
>>     
>
> It's about "what does the OS do when it needs to tell the user there's
> been a problem but can't talk to the user using the normal console/s
> for any reason (regardless of what the normal console/s are and
> regardless of what the reason/s may be)".
>
>   
If you put it this way it's configuration



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

signature.asc
Description: OpenPGP digital signature