Qestions about VESA/VBE

[Brendan]

Hi,

I dont understand the pixel formats in different bit depths. For example whats the format of placement of RGBA in a 24bpp or RGB in 16bpp?

I've never seen RGBA for 24bpp - normally there's only RGB, with "8-bit blue byte, then 8-bit green byte, then 8-bit red byte". For 16bpp normally the lowest 5 bits are for blue, then middle 6 bits are green and the highest 5 bits are for red.

In all cases, different video cards are allowed to do anything they like (e.g. 16bpp might be 5 bits for each with a spare bit for padding, or could be BGR instead of RGB, or 2-bits for blue and red with 12 bits for green, or anything else); and you should consult the bit positions and masks that VBE provides. This information should have been kept by the multi-boot boot loader (e.g. the "vbe_mode_info" pointer at offset 76 in the Multiboot information structure should point to the VBE mode info that contains the bit positions and masks that you need to use).

How windows loads 32bpp by deafult? Does windows pack drivers for all vga cards? Or how linux does it? When linux boots, its still in textmode then it changes the console resolution. Whats the trick behind these OSs that they support 32bpp and can change the resolution or bit depth at any time?

They use whatever the firmware provides to set an initial video mode during boot (e.g. VBE for BIOS or GOP/UGA for UEFI), and then start a native video driver for switching video modes after boot.

Note: Writing native video drivers sounds extremely hard; and to be honest it is extremely difficult if you want a full function native video driver. However; native video drivers that are only able to change video modes (and don't support fancy features like hardware mouse pointers, overlays, 2D/3D acceleration, shaders, GPGPU, etc) is probably a lot easier than most people realise.


Cheers,

Brendan

[rdos]

To make it work:

• Inside the CPU there's special support to handle the caching of obsolete/legacy areas (the "fixed range MTRRs")
• Inside the memory controller there's special support to determine if reads and writes to the obsolete/legacy areas get forwarded to RAM or to PCI
• In all PCI bridges (including the host controller) there's special support to forward accesses to the obsolete/legacy VGA IO port range and forward accesses to the obsolete/legacy VGA IO "display memory window". Note: see the "VGA Enable" bit (bit 3 of the bridge control register) in your favourite copy of the PCI-to-PCI Bridge Architecture Specification
• In all video cards there's special support to handle the legacy VGA IO and memory accesses

The only legacy-IO I depend on right now is the hardware cursor (if these ports doesn't work, it's no big deal). I certainly don't use video-modes that use real-mode addresses (typical LFBs from VBE are in the 32-bit address space, not in the real mode address space).

Thus, your points above might be relevant for an really ancient DOS-system running in real-mode, but it is not relevant for me. The only function I want is the ability to switch video-mode, and to get mode info like LFB address from VBE.

Of course when there are multiple video devices, only one video device can receive the obsolete/legacy VGA accesses at a time. For this reason, all PCI video devices are fully functional without any of the obsolete/legacy VGA stuff listed above (otherwise you'd only ever be able to use one video card in a system).

You could keep more than one copy of the video code at the same time, switching which VBE to switch mode on. So this should not be a problem really. Access to hardware cursor register wouldn't work though (at least not without some substantial hacks).

OTOH, supporting multiple video cards is not a high-priority issue. Seems pretty obsolete to me.

If you were designing a new OS today; it'd be extremely foolish to expect VBE (or any of the obsolete/legacy support the hardware needs to provide to make VBE work) to exist 10 years from now - it would be a massive mistake. If you designed an OS 20 years ago, then you couldn't have foreseen the death of the BIOS/VBE, so relying on the existence of VBE would've been perfectly understandable back then (but the clock is ticking and you'd want to start changing the OS to suit "pure UEFI" now so that your OS doesn't end up on the "unusable/obsolete" list itself).

I will support pure UEFI eventually, but I certainly will not drop VBE-support, and probably will use it as the primary alternative given the problems with GOP. Unless I decide to do a native driver for some platforms (like the AMD platform).

[Antti]

However; native video drivers that are only able to change video modes (and don't support fancy features like hardware mouse pointers, overlays, 2D/3D acceleration, shaders, GPGPU, etc) is probably a lot easier than most people realise.

My graphics API will be based on something like "DrawLine", "DrawPrimitive", "DrawText", et cetera. I have not designed it yet but it will be resolution-independent and applications will not modify pixels directly. To be realistic, my video driver will need a linear frame buffer. I do not think any other option is realistic for a small hobby OS. As much as I hate the word "hobby"...

However, it looks quite good now. I can get a linear frame buffer either from VBE or from GOP. Because of this, I would say that an extremely wide range of computers is supported. I do not need a driver to set the actual mode because it is already set up for me when the OS starts or the OS will run "headlessly". In my case the video driver is more like a render driver. The only thing the render driver does is to render the content to the linear frame buffer (multiple monitors could be supported also). Of course, this is not very trivial because a set of different pixel formats must be handled and there must good software render functions to draw primitives as efficiently as possible. This design does not prevent using hardware acceleration but I do not think it would become reality.

Too long; did not read? I would be extremely happy if the thing you said about the easiness of changing video modes is true. I am not asking much from the native video driver: just set me a video mode. My render driver would take care of the rest if it got enough information (LFB address, pixel format, etc) from the "low-level" video driver.

Do you think the whole concept of "linear frame buffer" is something that can be relied on like this?

[Brendan]

Hi,

To make it work:

• Inside the CPU there's special support to handle the caching of obsolete/legacy areas (the "fixed range MTRRs")
• Inside the memory controller there's special support to determine if reads and writes to the obsolete/legacy areas get forwarded to RAM or to PCI
• In all PCI bridges (including the host controller) there's special support to forward accesses to the obsolete/legacy VGA IO port range and forward accesses to the obsolete/legacy VGA IO "display memory window". Note: see the "VGA Enable" bit (bit 3 of the bridge control register) in your favourite copy of the PCI-to-PCI Bridge Architecture Specification
• In all video cards there's special support to handle the legacy VGA IO and memory accesses

The only legacy-IO I depend on right now is the hardware cursor (if these ports doesn't work, it's no big deal). I certainly don't use video-modes that use real-mode addresses (typical LFBs from VBE are in the 32-bit address space, not in the real mode address space).

Thus, your points above might be relevant for an really ancient DOS-system running in real-mode, but it is not relevant for me. The only function I want is the ability to switch video-mode, and to get mode info like LFB address from VBE.

Are you sure you don't have some sort of mental condition (I'm guessing maybe early dementia)?

If it's impossible for VBE to work (because VBE and all the obsolete/legacy hardware stuff that VBE relies on is gone), how on earth do you expect to be able to use VBE to set video modes?

Of course when there are multiple video devices, only one video device can receive the obsolete/legacy VGA accesses at a time. For this reason, all PCI video devices are fully functional without any of the obsolete/legacy VGA stuff listed above (otherwise you'd only ever be able to use one video card in a system).

You could keep more than one copy of the video code at the same time, switching which VBE to switch mode on. So this should not be a problem really. Access to hardware cursor register wouldn't work though (at least not without some substantial hacks).

OTOH, supporting multiple video cards is not a high-priority issue. Seems pretty obsolete to me.

In theory, the people writing UEFI firmware could map/unmap different video code into the legacy ROM area, map/unmap different video card "legacy display area" into the area at 0x000A0000, and configure/reconfigure anything else necessary; such that multiple video cards can use the obsolete/legacy VGA stuff at different times. Of course this is only "in theory", because in practice far better ways of doing it already exist and already work, and nobody is stupid enough to bother.


Cheers,

Brendan

[MadZarx]

I got it now. Theres no alpha in pixel formats and I should do the alpha blending myself. Anyway noI have written the alpha blending function. And does VBE gives supported screen resolutions and bit depths in an array or something?

[Brendan]

Hi,

However; native video drivers that are only able to change video modes (and don't support fancy features like hardware mouse pointers, overlays, 2D/3D acceleration, shaders, GPGPU, etc) is probably a lot easier than most people realise.

My graphics API will be based on something like "DrawLine", "DrawPrimitive", "DrawText", et cetera. I have not designed it yet but it will be resolution-independent and applications will not modify pixels directly. To be realistic, my video driver will need a linear frame buffer. I do not think any other option is realistic for a small hobby OS. As much as I hate the word "hobby"...

However, it looks quite good now. I can get a linear frame buffer either from VBE or from GOP. Because of this, I would say that an extremely wide range of computers is supported. I do not need a driver to set the actual mode because it is already set up for me when the OS starts or the OS will run "headlessly". In my case the video driver is more like a render driver. The only thing the render driver does is to render the content to the linear frame buffer (multiple monitors could be supported also). Of course, this is not very trivial because a set of different pixel formats must be handled and there must good software render functions to draw primitives as efficiently as possible. This design does not prevent using hardware acceleration but I do not think it would become reality.

That's how it should be done - providing a usable fall-back for "no native video driver" that works for all cases (including future UEFI), while not preventing native video drivers (that support video mode switching and advanced stuff like hardware accelerated 2D/3D) so that one day someone (not necessarily the OS developer) can write native video driver/s that makes all the existing applications (that were using software rendering) much much faster without breaking anything (or requiring graphics API redesign).

Do you think the whole concept of "linear frame buffer" is something that can be relied on like this?

Yes. As far as I know all systems provide some sort of frame-buffer as a "minimum functionality fall-back" (not just VBE/BIOS, UGA/GOP/UEFI; but also ARM and other systems).


Cheers,

Brendan

[Brendan]

Hi,

I got it now. Theres no alpha in pixel formats and I should do the alpha blending myself. Anyway noI have written the alpha blending function.

To get decent performance, video code tends to be very carefully designed to suit the specific case - it's a bad idea to adapt someone else's code (designed for a different specific case).

And does VBE gives supported screen resolutions and bit depths in an array or something?

VBE gives you a list of "video mode numbers" that are supported by the video card (but may not be supported by the monitor); allows you get information about any specific "video mode number" (e.g. so you can search through the video mode numbers until you find one that matches what you want); and allows you to set a video mode.

If you're interested in VBE, you should probably start with this wiki page and then read the VBE specification (link at the bottom of that wiki page).


Cheers,

Brendan

[rdos]

If it's impossible for VBE to work (because VBE and all the obsolete/legacy hardware stuff that VBE relies on is gone), how on earth do you expect to be able to use VBE to set video modes?

Huh?

How is it impossible for VBE to setup a LFB anywhere in physical memory (and especially at the address allocated to PCI at boot), and exporting only non-VGA modes that doesn't need neither the legacy memory buffer (0xA0000) or the legacy bit-plane registers?

How do you propose that VBE could setup a 32-bit LFB for 1366x768 at 0xA0000? Using 0xA0000 for the video buffer has been an impossible approach for a very long time, and VBE have supported these resolutions for a long time at other addresses.

[Brynet-Inc]

The VBE ROM might use the legacy I/O mappings to initialize the card, i.e: do the modesetting. You would be assuming that those mappings were configured by the firmware when you execute the VBE ROM in a non-BIOS environment.

An EFI expansion ROM might instead use the PCI BAR addresses with what's essentially a native driver for EFI firmware.

[MadZarx]

I've never seen RGBA for 24bpp - normally there's only RGB, with "8-bit blue byte, then 8-bit green byte, then 8-bit red byte". For 16bpp normally the lowest 5 bits are for blue, then middle 6 bits are green and the highest 5 bits are for red.

In all cases, different video cards are allowed to do anything they like (e.g. 16bpp might be 5 bits for each with a spare bit for padding, or could be BGR instead of RGB, or 2-bits for blue and red with 12 bits for green, or anything else); and you should consult the bit positions and masks that VBE provides. This information should have been kept by the multi-boot boot loader (e.g. the "vbe_mode_info" pointer at offset 76 in the Multiboot information structure should point to the VBE mode info that contains the bit positions and masks that you need to use).

Yeah I know that. All pixel formats are in RGB or BGR or other things but theres no alpha in them.
Thank you for the information

They use whatever the firmware provides to set an initial video mode during boot (e.g. VBE for BIOS or GOP/UGA for UEFI), and then start a native video driver for switching video modes after boot.

Note: Writing native video drivers sounds extremely hard; and to be honest it is extremely difficult if you want a full function native video driver. However; native video drivers that are only able to change video modes (and don't support fancy features like hardware mouse pointers, overlays, 2D/3D acceleration, shaders, GPGPU, etc) is probably a lot easier than most people realise.

So they all have native video drivers. How hard is it to write a native video driver to just change the resolution or bit depth? I'm sure I will need it because I will test my kernel on different machines when my memory manager and VFS is finished.

You could keep more than one copy of the video code at the same time, switching which VBE to switch mode on. So this should not be a problem really. Access to hardware cursor register wouldn't work though (at least not without some substantial hacks).

You mean I cant have a cursor on screen without a native video driver? Or your meaning of hardware cursor is an accelerated cursor?

My graphics API will be based on something like "DrawLine", "DrawPrimitive", "DrawText", et cetera. I have not designed it yet but it will be resolution-independent and applications will not modify pixels directly. To be realistic, my video driver will need a linear frame buffer. I do not think any other option is realistic for a small hobby OS. As much as I hate the word "hobby"...

However, it looks quite good now. I can get a linear frame buffer either from VBE or from GOP. Because of this, I would say that an extremely wide range of computers is supported. I do not need a driver to set the actual mode because it is already set up for me when the OS starts or the OS will run "headlessly". In my case the video driver is more like a render driver. The only thing the render driver does is to render the content to the linear frame buffer (multiple monitors could be supported also). Of course, this is not very trivial because a set of different pixel formats must be handled and there must good software render functions to draw primitives as efficiently as possible. This design does not prevent using hardware acceleration but I do not think it would become reality.

Too long; did not read? I would be extremely happy if the thing you said about the easiness of changing video modes is true. I am not asking much from the native video driver: just set me a video mode. My render driver would take care of the rest if it got enough information (LFB address, pixel format, etc) from the "low-level" video driver.

Do you think the whole concept of "linear frame buffer" is something that can be relied on like this?

First of all, I've read all your post My GFX functions take care of all drawing stuff such as drawing or filling boxes or circles and etc So as you said VBE and GOP will provide everything I need to have a working graphics. But not accelerated But now my video driver only supports 800x600 24bpp resolution because I've got the graphics in two last days and I will add support for other resolutions later

To get decent performance, video code tends to be very carefully designed to suit the specific case - it's a bad idea to adapt someone else's code (designed for a different specific case

Drawing on screen is just copying some bytes to frame buffer. I dont think there should be something faster than doing this

Code: Select all

buffer[position] = color.Red;

And I'm not using someone else code. The whole video driver is written by me. Not only the video driver, but also all other parts. Except the GDT and IDT and ISR assembly which I've used Bran's Kernel Development code because I didn't want to mess up with the GDT and IDT shifts. If I do a bit wrong, some unexpected results may happen and I will never find the source of that error

[Brendan]

Hi,

If it's impossible for VBE to work (because VBE and all the obsolete/legacy hardware stuff that VBE relies on is gone), how on earth do you expect to be able to use VBE to set video modes?

Huh?

How is it impossible for VBE to setup a LFB anywhere in physical memory (and especially at the address allocated to PCI at boot), and exporting only non-VGA modes that doesn't need neither the legacy memory buffer (0xA0000) or the legacy bit-plane registers?

This is as stupid as asking why you can't use "ROM BASIC" in a modern computer - if it no longer exists then obviously it can't be used.

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).


Cheers,

Brendan

[rdos]

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).

What you fail to understand is that old VGA modes with bitplanes do not interest me (have no support for them either). What a modern VBE gives you is the PCI BAR for the LFB. I could verify it, but this is the only reasonable address for high-res LFBs that won't fit betwen 0xA0000 and 0xBFFFF anyway. And if the cursor IO ports don't work that don't mean anything, as those are only cosmetic for text-mode.

[Griwes]

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).

What you fail to understand is that old VGA modes with bitplanes do not interest me (have no support for them either). What a modern VBE gives you is the PCI BAR for the LFB. I could verify it, but this is the only reasonable address for high-res LFBs that won't fit betwen 0xA0000 and 0xBFFFF anyway. And if the cursor IO ports don't work that don't mean anything, as those are only cosmetic for text-mode.

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).

I have a feeling that you need to learn to read, rdos.

[Brendan]

Hi,

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).

What you fail to understand is that old VGA modes with bitplanes do not interest me (have no support for them either). What a modern VBE gives you is the PCI BAR for the LFB. I could verify it, but this is the only reasonable address for high-res LFBs that won't fit betwen 0xA0000 and 0xBFFFF anyway. And if the cursor IO ports don't work that don't mean anything, as those are only cosmetic for text-mode.

If VBE doesn't exist; then it's impossible for VBE (which doesn't exist) to setup anything at all (including setting up any video mode that uses an LFB anywhere in physical memory).

In a similar way; if VBE does exist but the hardware it relies on to forward writes to legacy VGA IO ports doesn't exist, then VBE will be unable to set any video mode using those legacy VGA IO ports (including being unable to configure any video mode that uses LFB).

I have a feeling that you need to learn to read, rdos.

Yes.

To make this more clear; the video card may be setup for "native mode" where the video card's control registers and the video card's display memory are mapped into the "PCI hole" (such that none of the obsolete/legacy VGA stuff is needed at all); and this will work fine for "UEFI GOP" and for an OS's native video driver. However, VBE code runs in real mode and therefore will not be able to access the video card's control registers when they're mapped into the "PCI hole" (as real mode code can only access the first 1 MiB of the physical address space).

There are 3 alternatives. The first alternative is for VBE code to switch to protected mode or something so that it can access the video card's control registers when they're mapped into the "PCI hole". This would break a lot of code (e.g. any code that expects to be able to run VBE in virtual8086 mode, because you can't switch to protected mode while you're running in virtual8086 mode); and would therefore be completely stupid (no sane VBE code will ever be designed to support this).

For the second alternative; for some video cards it might be theoretically possible to map the video card's control registers to a range of IO ports (that are not the legacy VGA IO ports) so that they can be accessed in real mode. However; in this case the VBE code will still be designed to use (require) the obsolete/legacy VGA IO ports to access the video card's control registers, and it will not work in practice. Note: I'm not sure that any modern video cards would support this - no modern devices that need decent performance use IO ports anymore (excluding "legacy emulation").

For the third alternative; you could write your own VBE code that does support/use either of the methods above to access the video card's control registers. This is the only way that VBE can work in practice when the obsolete/legacy VGA stuff is gone. However, if you're writing your own "video control code" for each video card then it'd be extremely silly to implement it as VBE (and far more sensible to implement your own "video control code" as native video drivers for your OS instead).

Basically; once the obsolete/legacy VGA stuff is gone you can not use VBE to setup any video mode (including using VBE to setup an "LFB video mode"). Of course it's more likely that the VBE itself will be go first (and that support for the obsolete/legacy VGA stuff in chipsets, etc will go later); so code that's been designed by in idiot (that expects to use VBE when booted from UEFI instead of just using UGA/GOP) will probably be screwed for other reasons before its screwed for this reason.


Cheers,

Brendan

[rdos]

Hint for Brendan: PCI accesses can be executed in real mode, and the code setting up video mode doesn't need to be able to access the LFB.