OSDev.org

You are talking about this as if you would want to create the next big commercial OS. Providing multi-monitor support is a minor issue in an hobbyist operating system environment. We're mostly dealing with really important low-level stuff. Having multi-monitor support helps you nothing if you haven't a proper memory allocator.

Well, this thread is about graphics support, not memory allocators. Of course there's little point in worrying about graphics until you have the basics.

As for multi-monitor support, most graphics cards default to "mirrored" mode (or can at least be easily set to this mode with appropriate native drivers), which is fine for many scenarios, so all you have to do is select a resolution that's suitable for both attached monitors. This will likely require user assistance, since the OS doesn't know what the user considers "suitable" (e.g. if the monitors differ in aspect ratio, which monitor should display black bars or a stretched image?).

That being said, it's still a good idea to consider how full multiple monitor support will work when designing your graphics/GUI stack, even if you don't plan to implement it initially.

If you can't change resolution at runtime, the process of selecting a "suitable" resolution becomes rather tedious and annoying, since the user is likely to want to try multiple possibilities.

That is a good point. Relying on "runtime VBE" was a good idea 10-15 years ago if native video drivers were not available. There are pros and cons. In this aspect using "runtime VBE" might make your OS slighly better at the moment. However, that "pro" will not last in the long run.

Hi,



I've never seen laptops in a corporate environment running an OS without native video drivers.

Ideally, when users connect a monitor, you want the video driver detect that and automatically get the monitor's EDID, and automatically set a video mode (hopefully the monitor's preferred/native resolution). When users disconnect a monitor, you want to know that too (so that you can stop consuming CPU time generating graphics that will never be seen). For VBE the OS/video driver won't be notified when a monitor is connected/disconnected at all; and if the user is connecting a second monitor (where the laptop's built-in screen is the first monitor) you can't use VBE to set a video mode for it anyway (as VBE doesn't support multiple monitors).



If VBE doesn't exist, it's impossible to use it (and "hard" is easy compared to "impossible").

The big name OSs started using VBE about 20 years ago, when OSs like Win95 had to be able to run DOS applications (for marketing/backward compatibility reasons) and a big fat emulation layer had to be built into the OS anyway. Now, if they actually do still use VBE after boot it's extremely likely that the only reason they're doing it is because they're too lazy to rip out the old code they already had.



If you use VBE (or "VGA BIOS functions", or UGA/GOP for UEFI) during boot you don't have to worry about a VGA driver (or low resolution/colour depth video modes) and you're still able to display a UI for anything. If the video card is so messed up that you can't use VBE (or "VGA BIOS functions" or UGA/GOP) during boot, then treat the computer as "headless" (until/unless there's a native video driver); or (if you don't support headless systems) display a "video card is unusable" error message (in text mode, or using "console output" on UEFI) and refuse to boot.


Cheers,

Brendan

As I've said multiple times already, obviously native drivers are the goal. However, when they are not available you have to do something sensible.

"Blindly" relying on EDID is often a bad idea. Sometimes the user may have a different preference (for whatever reason) or it might be simply non-available (e.g. a KVM switch is in the way - modern Linux distributions are awful in this case). User preference should take precedence over auto-detection. However, giving the bootloader access to user preferences isn't all that straighforward. Either you have to update the boorloader's configuration every time the user changes something, or you have to extend the bootloader to read the OS's configuration. The latter means that the bootloader needs to be able to read your filesystem, parse your configuration files, etc. and either way, you're introducing "tight coupling" between the bootloader and OS; something that the multiboot standard was designed to avoid.

In most cases, until you've got full native drivers and full multi-monitor support, you'll be using "mirrored" mode, which is usually the default (and often works with VBE). Displaying different pictures to the monitors is another task altogether.

Except that it does exist and can (probably) be relied on to exist for approximately another decade. (Outside of a few specialised devices/tablets and Apple systems, I don't see the BIOS CSM going anywhere quite yet.) Note that even for OSs that support (U)EFI boot, many drivers still require the CSM to be loaded (e.g. AMD graphics drivers on Linux).

The hardest part about having native drivers isn't the time and effort required to develop them; it's fact that you need the hardware to do so. So, unless you've got a big pile of money/hardware, it's largely impossible for a hobbyist.

That's not right at all. Windows 9x never had any official VBE support. Their "fallback" was standard VGA. It was the 2000/XP era when Microsoft added appropriate drivers to Windows. Even Windows 10 has full support. Mac OS X has full VBE support (and can boot from BIOS), despite never officially supporting any hardware where it's needed. VBE support is poorest, but still available, on Linux (although Linux can also use a framebuffer set up by a bootloader).


There's no reason why you can't have multiple "fallback" options and there's no particular disadvantage to having a standard VGA driver in addition to other options. At the very least, part of it is going to be needed to display that text-mode error message...

Just an historic side note, I just checked an old DOS game and there were many vendor-specific (e.g. ATI, CIRRUS, etc.) TSR programs that implement the VBE interface. So it was not only the ROM that provided the interface but it was a driver interface also. Interesting but not very useful... please continue.

Hi,



Where "something sensible" is using VBE, VGA or UGA/GOP during boot to setup a video mode; and doesn't include wasting time with virtual80x86 mode and/or an emulator (for long mode) or doing things like diddling with chipset to try force the video card's ROM to work on UEFI, when you could've used that time to implement (basic/unaccelerated) native video drivers for one or more video cards instead.



The goal is to make the user's life easier (and not waste their time by forcing them to cope with a bunch of hassles when it could've been avoided). Part of this is "Plug & Play" - auto-detecting and auto-configuring hardware so the OS just works. There are cases where it's not possible and end-user hassle can't be avoided (and you do need usable work-arounds), but that's far less common and shouldn't be used as an excuse to avoid auto-detection and auto-configuration that does benefit most users most of the time.



It's not that hard, and it's very likely that you're going to need some way to pass settings to the boot loader for other reasons anyway.



It might take up to 10 years for BIOS to go away completely; but it also might take 10 years for your OS to become "feature complete" too; which means that it's likely that BIOS will be gone before your OSs is ready for actual use.

Also note that the main reason BIOS CSM still exists now is companies using Windows XP. Windows XP support ended in April.



You don't need to cover all hardware yourself. The idea is to make the OS "impressive enough" that other people are willing to help. This may mean family and friends that are willing to let you use their computer to test your drivers; and may mean other programmers see your OS and are willing to write drivers for you.

You also don't need to do this immediately. You might not be able to afford a video card now; but that doesn't mean you won't be able to afford a video card in the next 10 years.

Also note that with a single "ATI AtomBIOS" driver and perhaps 3 Intel video drivers, you've got about 90% of computers covered; and that setting up a video mode during boot is still "good enough" when there's no native driver.



Windows 9x had a big fat emulation layer for running DOS programs; including emulating hardware like the PIC, PIT, RTC, PS/2, etc; and including emulating the IVT, BDA, etc. It needed this big fat emulation layer because DOS programs were allowed to mess with hardware directly. If you've already got a big fat emulation layer like this, the amount of extra work involved in allowing the OS to use it for video mode switching is almost nothing.

If Microsoft didn't need the big fat emulation layer for DOS programs, would they have bothered supporting "driver-less video mode switching after boot"? My guess is that they probably still would have, because they've got thousands of developers and it made more sense before UEFI existed, before multi-monitor became common, before people started expecting high resolutions, before LCD monitors existed that can only display one resolution (and do a low quality rescaling internally when they don't get that resolution). I assume that you don't plan to support legacy/DOS programs, and that you don't have thousands of developers, and that it's not 1990 anymore.

Also note that on UEFI; when there's no native driver Windows does not support video mode switching after boot.

OS X does not have VBE support ("boot camp" might have, but that's not OS X). They also have the least reason to bother - their (80x86) systems are UEFI anyway, and they only need to support the small number of video cards that they've chosen to provide (and don't need to support "white box" hardware like Windows or Linux does).

Linux is a random group of people doing anything that want. It's never an example of good engineering.



You're right - there's no reason you can't waste a lot of time on irrelevant stuff that users don't care about (instead of spending that time doing more important things that users do care about).


Cheers,

Brendan

This is inherently contradictory. You can't have both CSM BIOS boot and UEFI boot simultaneously.

If you booted from UEFI, the CSM is not involved (except if the UEFI implementation was implemented on top of a legacy BIOS, in which case it might have indeed used a BIOS like environment). Assuming anything like a BIOS environment was ever setup or existed is an idea which will cause you problems.

Hi,



To clarify, let me enumerate (in loose chronological order):

Old BIOS systems with no VBE: This is hardware from (roughly) 1990 or earlier, before VBE existed (where SVGA cards needed their own driver code, often built into the applications themselves).

BIOS systems with VBE: This is hardware from maybe 1990 to 2010 (up until Intel said "All systems will support UEFI" when they released Sandy Bridge).

UEFI+BIOS systems that are using BIOS: This is hardware from maybe 2010 to 2012 (up until Microsoft wanted UEFI secure boot for Windows 8 ).

UEFI+BIOS systems that are using UEFI, but the firmware used VBE as the back-end for UGA/GOP and didn't clean up its mess when you called "exit boot services" function. In theory you might be able to use the shattered remnants of VBE in some way. In practice it's a massive mess (so many potential problems that's not worth bothering with).

UEFI+BIOS systems that are using UEFI, that have discrete video cards where the video card ROM supports VBE: In this case there's no VBE at boot; but in theory you can manipulate the chipset and video card ROM to be able to use VBE after boot. Of course in practice it's a massive mess (so many potential problems that's not worth bothering with).

UEFI+BIOS systems that are using UEFI, but have on-board video: In this case there's no VBE at boot; and (in theory) you may or may not be able to manipulate the chipset and video card ROM and use it after boot. The (additional) problem here is that the video ROM is often built into the firmware and very difficult to find (e.g. compressed to save space using an unspecified vendor specific compression method).

UEFI only systems, where the firmware used VBE as the back-end for UGA/GOP and didn't clean up its mess when you called "exit boot services" function. Not useful in practice.

UEFI only systems that have discrete video cards where the video card ROM supports VBE: In this case there's no VBE at boot; but (in theory) you can manipulate the chipset and video card ROM and use it after boot. Not useful in practice.

UEFI only systems that have on-board video: In this case there's no VBE at boot, no video ROM and no VBE in firmware. This is already happening (mostly for cheaper/mobile systems) and is likely to become common (even for "white box desktop/server") within the next 5 to 10 years.

UEFI only systems that have discrete video cards where the video card doesn't support VBE: In this case there's no VBE at boot and no VBE in the video card's ROM. This will take the longest amount of time to happen; however, discrete video cards are becoming "rare/esoteric hardware" (e.g. Intel already has the largest market share for video cards at about 62%) and it wouldn't surprise me too much if discrete video cards stop existing before they make the "no legacy puss" transition.

Please note that it's an extremely bad idea to assume that you can write an OS instantly. If you estimate that it's going to take X years to "finish" the OS, then it's best to design the OS for the hardware people will be using in X years time (and forget about designing the OS for the hardware people are still using now). Note: I think this is the thing that mallard just doesn't understand.


Cheers,

Brendan

Waaay to much here to go through each point individually, however:

Use of BIOS services after (U)EFI boot: Microsoft and Intel describe multiple "classes" of UEFI systems. "UEFI class 0" is BIOS. Class 1 is UEFI firmware that only supports a BIOS CSM (the vast majority of final-generation BIOS systems). Class 2 is a system that has a CSM permanently loaded to support BIOS-dependent hardware, but can boot via UEFI. Class 3 is UEFI-only/UEFI with CSM completely disabled.

Class 2 systems are required to support the BIOS INT 10h interface even when booting from UEFI. It's not a mistake or a failure to "clean up", it's part of the spec. (See Intel's CSM spec, where it lists "Valid EFI and Legacy Combinations", which include the availability of BIOS ROMs, including the video BIOS, to EFI-based OSs). "Class 2" also exists to support things like SCSI/RAID controllers that don't have EFI firmware.

Virtually all "PC" devices on the market today are class 2 systems. Macs are class 3 (except when booting via the CSM, when they act like class 1). The only OSs I know of that currently support boot on class 3 systems are Mac OS X and Windows 8 and later (maybe some Linux systems can, depending on the hardware).

Autodetection of graphics settings: I'm not saying you should never auto-detect the "best"/"native" settings, only that you need to provide the user with a way to override it. There are many legitimate reasons why they might want to do so (e.g. "best" resolution has a low refresh rate, display "splitter" device in use, EDID not available due to KVM, etc.).

CSM being exclusively for Windows XP support: Note that the original release of Windows Vista also doesn't support UEFI (added in SP1) and neither do the 32-bit versions of Windows Vista or 7. Windows 7 64-bit only supports UEFI class 0/1/2 systems. It's also still common to see DOS-based firmware update methods (DOS is inherently BIOS-dependent), as well as OEM restore disks that use BIOS boot, etc. The CSM isn't going away anytime soon.

Personally, I find the idea that any OS is ever "feature complete" somewhat strange. Has any general-purpose OS ever reached a "finished" state and ended development? My OS is designed to support both legacy and current hardware (300-400Mhz Pentium-class CPUs with as little as 128MB RAM are one of my targets, e.g. 86duino and Intel Galileo boards). I'm also considering making a minimal version that would run on an 80386 with 6MB RAM, since I have an old laptop with that spec. If you only want to support future hardware, then it could make sense to go UEFI-only, but that's not the direction I'm intending to go.

Hi,



CSM has 2 purposes. To boot OSs that don't support UEFI, and to support device ROMs that don't support UEFI. For the first case, from the OS's perspective it's identical to a "BIOS only" system (the UEFI interfaces aren't exposed to the OS and the OS can't use them).

For the second case, from the OS's perspective it's identical to a "UEFI only" system. The CSM interfaces aren't exposed to the OS and the OS can't use them; and when the OS calls "exit boot services" it should all disappear (any RAM it used is freed/reclaimed, etc). In this case, CSM is essentially an irrelevant "internal implementation" thing.

All 80x86 OSs that support UEFI support "class 3" (because there is no practical difference from the OSs perspective whatsoever). Note: Some OSs do have a dodgy hack where they try to extract the legacy/BIOS ROM from video card and run it under emulation (e.g. X11); but this has nothing to do with CSM at all, and no version of Windows has this dodgy hack. It's very likely that the dodgy hack itself came from a desire to use PCI video cards on other CPUs (PowerPC, SPARC, etc) before UEFI even existed.



I never said CSM is exclusively for Windows XP support (and this doesn't even make sense anyway). After motherboards stop providing the ability to boot legacy OSs, they may still support legacy device ROMs (and still use CSM for that).

For the ability to boot legacy OSs; it's mostly about marketing. Motherboard manufacturers currently provide the ability to boot a legacy OS because enough customers still want it; and enough customers still want it because of Windows XP. Yes, there may be an insignificant minority that want to run even older OSs, but they are an insignificant minority (irrelevant for marketing purposes).

Windows doesn't support 32-bit UEFI because computers that provide 32-bit UEFI are extremely rare ("white box 80x86" switched to 64-bit before the switch to UEFI really began); and while there are a few 32-bit UEFI systems (mostly old Macs and nothing else) they support BIOS anyway. Essentially there's very little incentive for Microsoft (or anyone else, except Apple) to care about 32-bit UEFI on 80x86.



This is exactly why I've been putting it in quotes (e.g. "feature complete" and not feature complete). What I mean is "reached a state where the OS is actually a viable alternative to existing OSs for normal users".



Your OS is designed to support legacy and current hardware (excluding future hardware)? In that case you could probably forget about UEFI.


Cheers,

Brendan

That's incorrect. Read Intel's CSM Specification. "If an EFI OS is booted, then OpROMs can be either EFI (preferred) or traditional."

"It is expected that there will be a light and full version of the Legacy BIOS Protocol. The light version is for environments where the OS is always an EFI-aware OS that might have traditional OpROMS."

The "firmware test suite" for Linux checks to see if the firmware includes a CSM by attempting an INT 10h call. I doubt that this is violating the spec.

You can test it yourself by attempting to boot a Mac (a class 3 system) with AMD graphics from a UEFI-enabled Linux boot source. It will hang during boot when the graphics driver tries to load, because it needs to access the Video ROM. On a PC (class 2) it will work fine. If you install and configure something like rEFInd on the Mac (which enables a CSM-present EFI boot, i.e. makes the system "class 2") it will also work.

Again, incorrect. Microsoft says the following about Windows 7/Server 2008:
"Are not supported on Class 3 systems, because these operating systems assume the presence of legacy BIOS INT10 support in the firmware, which is not available in a Class-3 UEFI implementation."

"Windows 8.1 and Windows® 8 support native UEFI 2.0 or later on 32-bit (x86), 64-bit (x64), and ARM-based PCs."

My design is simply to leave the firmware interface as much as possible up to the bootloader. Since there are multiboot-complain loaders for both BIOS and (U)EFI, the the OS only needs to care if/when it accesses firmware services. Therefore, I'll be able to use VBE if it's available and fall back to something else if it isn't. If the bootloader has configured a framebuffer, I might be able to use it. If it hasn't and there's no VBE available or compatible native driver, the only option left is standard VGA. Which is fine by me.

Supporting hardware that doesn't exist yet is pretty much impossible. The best you can do is support current hardware and hope that new systems are backwards-compatible. (Thankfully, x86 PCs have long valued that sort of backwards compatibility. OSs designed for PCs/XTs can still boot on most modern systems.)

As an aside, GRUB has a "loadbios" command that can be used to load a video BIOS from disk. This can be used to enable VBE support on "class 3" systems (assuming you've previously extracted the BIOS from the video card or have a compatible BIOS from another source, e.g. the vendor's website, assuming it has one).

Hi,



Sure: "The light version is for environments (where the OS is always an EFI-aware OS) that might have traditional OpROMS (that the OS can't really know about and shouldn't attempt to use, that only exist for the firmware/environment's internal use and nothing more)."

The only things a UEFI OS can rely on are the things documented in the UEFI spec; not the "hidden behind the scenes" things that are documented in the CSM spec or the PIE spec. These specs are intended for firmware developers, not OS developers.



It's extremely retarded. There isn't even any guarantee that there's a valid (real mode) IVT.



This only proves that "attempting an INT 10h call" is retarded and doesn't work; and that Linux is a dodgy piece of crap. This is nothing new (e.g. have a look at how Linux handles the UEFI memory map).



You're right - I should've said "All 80x86 that aren't dodgy pieces of crap support UEFI "class 3" (because there is no practical difference from a well designed OSs perspective whatsoever)". Fortunately it seems Microsoft fixed their OS 5+ years ago, so it only really applies to versions of the OS that weren't originally intended for UEFI in the first place (e.g. where UEFI support was retro-fitted after release).



You won't even be able to determine (reliably) what sort of firmware exists; and won't know if VBE is available or not.



Wrong. You can make educated guesses and prepare for foreseeable future hardware differences; including "class 3 UEFI", including systems where PCI bridges aren't configured to route "legacy VGA accesses" to any of the video cards, including systems with insanely high resolutions ("10240 * 5760"? Sure, why not), including things like (e.g) 3D VR headsets, including 1024-bit AVX, including systems with more than 256 CPUs, etc.



So? If there's a right way to do something (that's guaranteed by official specifications to work) and a wrong way to do something (that relies on dodgy hacks and obsolete puss); then with thousands of incompetent fools writing open source software you can bet that at least one of them going to do things the wrong way. The sad part is that all of these people (and you) are too stupid to understand the difference between "works" and "only works for me for now".

Please note that all of this is entirely irrelevant, as you've completely failed to explain why an OS would be so poorly designed that it needs to switch video modes after boot without a native driver. It's like you're obsessed with wasting time to do things wrong, just to provide something that should never be needed in the first place.


Cheers,

Brendan

If you want to dismiss all mainstream OSs as "retarded" then that's fine. I believe that all software is "bad" in some way or another, just to varying degrees.

I will note however, that if Windows requires something, then it will be available on all PCs for quite some time. Like it or not, Microsoft is in de-facto control of the "PC" platform (with assistance from Intel). Nobody is going to built a PC/motherboard that's not compatible with Windows (or even requires Windows 8+ outside of tablets for quite some time). Since Windows 7 requires INT 10h, even when booting via (U)EFI, then it will be available for the foreseeable future.



Read the real-mode IVT. If entry 10h is a valid entry and pointing to a readable memory address, it's probably valid. If, by chance, it's pointing to readable memory that doesn't contain a video BIOS then when when you try to run it with an x86 emulator or V86 mode process, it will fault in some way, almost certainly pretty quickly. If that happens, you can note it in a configuration file somewhere and don't attempt it in future. VBE availability detected.

The multiboot structure tells you all you need to know if you're planning to use a bootloader-configured framebuffer. You don't need to know if you've got VBE or GOP.



So you've built an OS that supports all these things then? Or surely, you know someone who has? Some of those ideas will have no difficulty being supported by current OSs (e.g. "insanely high" screen resolutions; mainstream OSs have DPI scaling already). For others, we don't even know what the OS/hardware interfaces will look like (e.g. >256-way SMP), so it's impossible to support them. You can design with the possibility in mind, but that's about it.

VBE and BIOS support isn't going away for the "foreseeable" future. It inevitably will, of course, and I'll design with that possibility in mind, but while the support is there, I may as well use it.



In the long-term, there is no difference. What "works" currently will eventually not work, no matter how good you are future-proofing. Better to design for what you have and what you can see on the horizon than spend enormous time and effort designing something "future proof" that inevitably ends up being proved not so.



We covered that ages ago. The "without a native driver" scenarios are exactly the same as the "with a native driver" scenarios, except that the user is using hardware that you haven't been able to build a native driver for. (Personally, I'm hoping that some initiative like CDI will result in a decent range of ready-made OS-neutral device drivers being available to hobbyists).

What's an important part of the problem is that many native graphics drivers are heavily dependent on the presence of the Video BIOS.

The thing here is that graphics hardware is not unique. It was common practice for a manufacturer to distribute a chip, have a licensor put that chip on a board, have him add a ISA/PCI*/AGP/... connector of his choice, memory modules of his choice, and clocks of his choice. This would then get reselled under the brand vendot's product line and you had to be really careful about what it really was because names were pretty distracting. This practice has well continued into the modern generation, although it became more obvious to ask for either a radeon or nvidia, and the brand name came second place in importance.

Regardless, you had many chips with the same PCI ID - if it had one - and what happened afterwards is that the remainder of the configuration was stored at a fixed address. This would tell the driver the RAM, clock and DAC properties it needed to reconfigure the clocks to provide stable graphics output on non-VGA resolutions. This has the unfortunate consequence that drivers have to depend on the firmware to provide part of their configuration, and for any pre-EFI images, this is the legacy video ROM.

This practice is known to continue into the latest NVidia series of video cards.

The consequence is obvious: drivers depend on the legacy BIOS being loaded because they would be unable to configure the video card otherwise. This gives a whole slew of backwards compatibility issues for drivers that aren't aware that the firmware might not be present at all times, and probably a significant part of the reason why firmware is consistently loaded at the "usual" address.