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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel