OSDev.org

tom9876543 wrote:I am no expert but IMHO trying to get a fully operating VBE graphics mode is a waste of time. Unfortunately you really need to write native drivers. You can look at the Linux / BSD source code to help you. Be careful if you decide to copy it!

Slightly off topic.....

What is the graphics mode Linux goes into when it boots up and you see all the text messages with a Penguin at the top???? That is probably the limits of what can be achieved with VBE. Does anyone know what the relevant source code file in Linux is?

Yes, you most definetly are no expert, unless you have something to back up your claim that VBE is a waste of time. If you don't even know what the limits of VBE are, how can you even make such a comment? VBE allows access to high resolution/bit depth modes... the limits are what you make of them. There were quite a few games that used VBE before windows got anywhere near decent, and is still relevant when specific video card drivers can't be found under both linux and windows. Yes, without hardware acceleration, the drawing routines are slower... but at least they work.

VBE is not a waste of time, and you can even get acceptable performance from it. Also, a lot of code you write for a VBE driver can be used in your card specific code as well. VBE is very easy to get into (especially if you do so before going to pmode), any somewhat recent card (like... 1995+) supports linear frame buffers, and you can do high resolution graphics without trying to trek through tons of cryptic documents just to get it working on a single machine. I think it would be silly not to write a software driver before attempting to write hardware specific stuff, if not just to have a reference that you know your graphics code/gui stuff is working properly, and the reason it's displayed incorretly is in fact something driver related, not implementation of drawing functions related. Especially with something so simple as VBE.

Hi,

Combuster wrote:

Brendan wrote:Ideally the OS will (eventually) have native video drivers; and IMHO (for a serious project) supporting any fallback method of video mode switching after boot (used when there's no native video driver) isn't worth the hassle - it's a short term gain (that causes long term pain).

Never tried using a VGA driver as fallback?

If your boot code switches to a modern video mode during boot then a VGA driver won't be able to change video modes correctly (as that would require resetting non-VGA extensions to disable the non-VGA video mode). If you limit the OS to VGA video modes (during boot and after) then the first problem goes away, but then you're limited to horrid (low resolution/low colour depth) VGA video modes; and you still risk the need for a fallback for your fallback (in cases where the video card has compatibility problems).

It's probably worth looking at what normal people expect. I'm not sure about everyone else, but (at a minimum) I expect video drivers that support 2D acceleration, multiple monitors (either dual head video cards or multiple video cards) and the monitor's preferred resolution (which is often a 16:9 or 16:10 aspect ratio now - e.g. 1920 * 1080, 1600 * 1200 or 1920 * 1200). Both VBE and VGA fail for all of these things.

The only way to not fail to meet the user's minimum expectations is to provide native video drivers. This is a nightmare (even when documentation is available the complexity of "doing it right (tm)" is scary), but it's still the long-term goal. The short-term goal is to (attempt to) minimise the user's disappointment until the long-term goal is achieved.

For a modern video driver interface (e.g. something with resolution independence) people don't switch video modes after they get the OS setup (unless they're playing games that will suck badly without 2D/3D acceleration anyway). With this in mind, the ability to switch video modes is far less important than the ability to use high resolution video modes (even if they aren't the monitor's preferred resolutions). Therefore, minimising the user's disappointment means using VBE (or the U/EFI API, or whatever interface the "pre-boot environment" supports) to configure a reasonably modern high resolution video mode.

The other thing to consider is hassle. How much hassle is the fallback worth (given that it's only a short-term goal, and that it will fail to meet the user's minimum expectations regardless of how much work is required)? Everyone probably has different opinions, but for me, I've never considered the hassle of implementing a virtual8086 monitor to be justified (even back when "PC BIOS" was the only firmware to consider for 80x86). To be honest, I used to think a VGA driver was worth the time, but user's expectations and my opinion have changed in the last decade or so.


Cheers,

Brendan