OSDev.org

Hi,



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).



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

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.



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.



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).

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?

Hi,



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?



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

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?

Hi,



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).



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

Hi,



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).



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

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.

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.

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


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 mean I cant have a cursor on screen without a native video driver? Or your meaning of hardware cursor is an accelerated cursor?


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


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

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

Hi,



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

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.

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

Hi,



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

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.