Hi,
glauxosdever wrote:
I initially excluded "raw framebuffer", partly because I expected some native video driver to set up a good video mode (instead of covering the initial lack of drivers with a framebuffer), partly because on some old computers VESA/VBE may not be supported (and I'd need additional code for VGA instead) and partly because having boot code handle all of the complexity needed for setting up a good video mode that native drivers could instead handle themselves would turn the bootloader into a massive component.
But maybe having a framebuffer is better than having a "native" VGA driver ("native" is inside quotes because I don't consider a VGA driver native for an e.g. Intel GPU, but not having a framebuffer would make it more apparent that a native driver is needed and it would motivate me better to write one). Maybe if VESA/VBE is unsupported, it's fine not to support that computer (or fallback to VGA).
For "no VBE" (assuming BIOS) I fall back to the older "int 0x10" BIOS function; but I only support graphics modes that have a linear frame buffer which excludes everything except 300*200 with 256 colours. For "no UGA and no GOP" (assuming UEFI) and for "no VGA or better video card" (for BIOS) I treat it as a headless system (different beeps so you have some idea of how far it got, serial port output, ...).
For "no EDID" (including none explicitly included and configured by the user to be used as a work-around) I restrict it to VESA's Safe Mode Timing (which is mostly just the 640*480 timing used by VGA anyway); so the best you can hope for in that case is 640*480 with 16 million colours.
glauxosdever wrote:
Maybe it's fine to have the boot code query EDID and check which modes can be safely set.
For this; I get the EDID and do some relatively insane shenanigans to try to make ensure I only set the best and most likely to be supported video modes; but VBE doesn't give you timings and it's impossible to provide guarantees (e.g. VBE might say there's a "640 * 480 with 16 million colours" video mode, but you can't know if it's 60 Hz, 90 Hz, 120 Hz, and even then you can't know if it's a relatively standard timing for that refresh rate or something entirely bizarre).
In theory; for UEFI (UGA and GOP) the firmware is supposed to make sure that only video modes that the monitor supports are mentioned, so in theory you don't need to check. However, without parsing the EDID there's no way to figure out things like (e.g.) if a video mode matches the monitor's preferred resolution (and more complex stuff, like which colour space the monitor uses); and if you have the code (for BIOS) anyway then there's little harm in treating UEFI the same as BIOS.
glauxosdever wrote:
And for UEFI, where text mode doesn't exist AFAIK, I'd still need to set up a framebuffer. So I'll probably go with setting up a framebuffer and support drawing to it using callback functions to the BAL.
The other thing that might be worth mentioning is that (unlike VBE) UEFI is able to support multiple monitors. During boot it'd be nice to setup a raw frame buffer for however monitors are present, and display the same thing on all monitors throughout boot (and be able to handle multiple monitors after boot when there isn't any native video driver).
Cheers,
Brendan