OSDev.org

MadZarx wrote: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?

MadZarx wrote: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?

Brendan wrote: 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

Brendan wrote: 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).

Brendan wrote: 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).

Brendan wrote: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.

rdos wrote:

Brendan wrote: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.

rdos wrote:

Brendan wrote: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.

Antti wrote:

Brendan wrote: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.

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

MadZarx wrote: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.

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

Brendan wrote: 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?

Brendan wrote: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).

Brendan wrote: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.

rdos wrote: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).

Antti wrote: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 wrote: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

buffer[position] = color.Red;

rdos wrote:

Brendan wrote: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?

Brendan wrote: 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).

rdos wrote:

Brendan wrote: 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.

Brendan wrote: 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).

Griwes wrote:

rdos wrote:

Brendan wrote: 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.

Brendan wrote: 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.