Qestions about VESA/VBE

[bluemoon]

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.

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"

Legacy devices may have IO port, however for modern card if the control registers are mapped using mmio and above 1MB then you won't be able to set video mode in real mode, even you can access PCI and get the BAR.

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

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"

Legacy devices may have IO port, however for modern card if the control registers are mapped using mmio and above 1MB then you won't be able to set video mode in real mode, even you can access PCI and get the BAR.

You don't need to access the LFB in order to set video-mode. For example, it could be done by accessing some PCI BAR mapped to IO-space.

Besides, it obviously works on all machines I've tested it on (at least 15-20 different models). All of these can set video mode with VBE running in V86-mode, and without entering protected mode. And I don't mean video modes based on the legacy 0xA0000 buffer and bit-planes.

Take this as an example that it works:
Sony Vaio machine, 1366x768 video mode using 24-bit LFB. This requires a memory buffer of 1366 x 768 x 3 = a little more than 3MB, which is impossible to map to real mode.

[MadZarx]

Hey dudes thanks for all of you cool information about VBE. You already answered many of my questions. Thank you so much.
But some questions are still in my mind. How hard is it to write a native video driver to change video mode in pmode or get 32 bpp with high resolutions? And how hard it will be to use accelerated 2D and some other rendering stuff?

[Brendan]

Hi,

Legacy devices may have IO port, however for modern card if the control registers are mapped using mmio and above 1MB then you won't be able to set video mode in real mode, even you can access PCI and get the BAR.

You don't need to access the LFB in order to set video-mode. For example, it could be done by accessing some PCI BAR mapped to IO-space.

This is one of the cases I covered in my previous post. I've copied it here because you were too stupid to bother reading it the first time:

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

Besides, it obviously works on all machines I've tested it on (at least 15-20 different models). All of these can set video mode with VBE running in V86-mode, and without entering protected mode. And I don't mean video modes based on the legacy 0xA0000 buffer and bit-planes.

You're a moron. You boot code using the BIOS and see that it works for BIOS, then make insane assumptions about booting from UEFI being identical. This is as idiotic as testing that hay works as a fuel for horses, then claiming that it's a good idea to stuff a car's fuel tank with hay.

Take this as an example that it works:
Sony Vaio machine, 1366x768 video mode using 24-bit LFB. This requires a memory buffer of 1366 x 768 x 3 = a little more than 3MB, which is impossible to map to real mode.

You're still a moron. You've ignored everything that was used to setup the video mode (which is where the problem is and is also what I've been talking about), and focused on the irrelevant LFB access that only happens after all the tricky stuff has already been done.


Cheers,

Brendan

[Brendan]

Hi,

Hey dudes thanks for all of you cool information about VBE. You already answered many of my questions. Thank you so much.
But some questions are still in my mind. How hard is it to write a native video driver to change video mode in pmode or get 32 bpp with high resolutions?

How hard it is depends on how much of the "foundation" you're missing, how much prior knowledge you have, and which video card it is.

For example, if you've already got code to enumerate a PCI bus (and configure BARs, start device drivers, etc); and already have a video driver framework (e.g. that implements whatever is needed to communicate with the OS/GUI/applications); and already have code to parse EDID; then most of the boilerplate code will have already been done before you start writing a native video driver (and writing a new native video driver will be a lot easier as it's just recycling existing code).

For prior knowledge, you mostly need to know how video timing signals work - how a main clock is used (and divided) to control things like porches/margins, horizontal/vertical sync, etc.

For which video card, that comes down to available documentation and/or example code.

And how hard it will be to use accelerated 2D and some other rendering stuff?

In general, everything is hard before you do it, and everything is easy after you've done it.


Cheers,

Brendan

[MadZarx]

Hi,
How hard it is depends on how much of the "foundation" you're missing, how much prior knowledge you have, and which video card it is.

I wanna write (Later) Nvidia GeForce graphics to just change the resolution and if I got enough time, add support for accelerated 2D graphics

For example, if you've already got code to enumerate a PCI bus (and configure BARs, start device drivers, etc); and already have a video driver framework (e.g. that implements whatever is needed to communicate with the OS/GUI/applications); and already have code to parse EDID; then most of the boilerplate code will have already been done before you start writing a native video driver (and writing a new native video driver will be a lot easier as it's just recycling existing code).

I have none of them But I will write codes for these things as soon as I could read data from CDROM or HDD to load drivers

For prior knowledge, you mostly need to know how video timing signals work - how a main clock is used (and divided) to control things like porches/margins, horizontal/vertical sync, etc.

For which video card, that comes down to available documentation and/or example code.

I have searched about Nvidia docs. But many sites (like wikipedia) says that they haven't provided any documentations for their graphics cards
So where the hell should I get information about their graphics card??

[Brendan]

Hi,

For example, if you've already got code to enumerate a PCI bus (and configure BARs, start device drivers, etc); and already have a video driver framework (e.g. that implements whatever is needed to communicate with the OS/GUI/applications); and already have code to parse EDID; then most of the boilerplate code will have already been done before you start writing a native video driver (and writing a new native video driver will be a lot easier as it's just recycling existing code).

I have none of them But I will write codes for these things as soon as I could read data from CDROM or HDD to load drivers

It's a much better idea to start with the simplest possible devices and progressively work towards more complex things. Video drivers can easily be the worst possible devices (especially if you're considering 2D/3D acceleration, shaders and GPGPU) and therefore should be left until last, and not done as soon as you can read data from disk.

For prior knowledge, you mostly need to know how video timing signals work - how a main clock is used (and divided) to control things like porches/margins, horizontal/vertical sync, etc.

For which video card, that comes down to available documentation and/or example code.

I have searched about Nvidia docs. But many sites (like wikipedia) says that they haven't provided any documentations for their graphics cards
So where the hell should I get information about their graphics card??

Video drivers can easily be the worst possible devices; and NVidia are the worst possible video cards. There is no documentation, and most of the (open source) code you can find is derived from painful reverse engineering (and therefore likely to be dodgy and/or wrong anyway). Note: For setting video modes on Nvidia cards (and not everything else) you should be able to get enough information from open source projects (e.g. Nouveau).

I'd recommend starting with something like CirrusLogic "CL-GD5446" (it's old and much simpler than modern cards, there's documentation online, and it's emulated by Bochs). Then I'd consider trying Intel's video (starting with their older stuff and working towards their most recent), partly because there's documentation for most of it and also open source code written by Intel, and partly because Intel's video has a higher market share than NVidia and ATI combined.

Also, please understand that you can't write all device drivers yourself (different manufacturers produce new devices faster than any one person can support). The only sane goal is to make the OS so impressive that other people want to write device drivers for it. The OS will be impressive enough with (e.g.) Intel's video alone.


Cheers,

Brendan

[MadZarx]

Hi,
It's a much better idea to start with the simplest possible devices and progressively work towards more complex things. Video drivers can easily be the worst possible devices (especially if you're considering 2D/3D acceleration, shaders and GPGPU) and therefore should be left until last, and not done as soon as you can read data from disk.

Yeah I'm gonna write that driver as the last one because working on a video driver is just the waste of time and nothing more I can use text mode until I get a fully working graphics.

Video drivers can easily be the worst possible devices; and NVidia are the worst possible video cards. There is no documentation, and most of the (open source) code you can find is derived from painful reverse engineering (and therefore likely to be dodgy and/or wrong anyway). Note: For setting video modes on Nvidia cards (and not everything else) you should be able to get enough information from open source projects (e.g. Nouveau).

So how linux initializes the highest resolution supported by video card? Does it use one of those open source projects? Or what about windows? Lets say windows XP or 98 which have very higher rendering speed than any other linux on my PC without the native drivers installed. I cant understand what they have done that they got this high rendering speed :O :O

I'd recommend starting with something like CirrusLogic "CL-GD5446" (it's old and much simpler than modern cards, there's documentation online, and it's emulated by Bochs). Then I'd consider trying Intel's video (starting with their older stuff and working towards their most recent), partly because there's documentation for most of it and also open source code written by Intel, and partly because Intel's video has a higher market share than NVidia and ATI combined.

1 question. Does each video card model have its own driver and instructions? I dont mean the brand, just the model And I currently have Nvidia on my machine. If one day I write the intel's video card driver for my OS, am I able to use that driver on my machine with Nvidia video card???

Also, please understand that you can't write all device drivers yourself (different manufacturers produce new devices faster than any one person can support). The only sane goal is to make the OS so impressive that other people want to write device drivers for it. The OS will be impressive enough with (e.g.) Intel's video alone.

Yeah I know that So lets make something better than windows

[rdos]

You boot code using the BIOS and see that it works for BIOS, then make insane assumptions about booting from UEFI being identical.

You are not reading properly. I already told you that I provided a dummy BIOS that only returned failure for all int 15h services, rerun the VBE entry-point (in V86 mode), and then can change to whatever video-mode I want by calling the VBE mode-switch entry-point (also in V86 mode). I didn't need any real BIOS for this, so can you explain why I can't do the same thing when I happened to boot with UEFI? And while you are at it, explain how video-cards can be run on other CPUs using emulators, where the emulated BIOS obviously didn't setting anything up?

I simply think that your knowledge about VBE is severely outdated. You seem to believe that VBE uses legacy 0xA0000 memory buffers, which is outdated by 10-20 years at a minimum. And for legacy IO, there never were any standard for how to setup a video-mode using legacy IO. It was chip-set specific at a very early point, and that was the motivation for VBE to begin with.

[Brendan]

Hi,

It's a much better idea to start with the simplest possible devices and progressively work towards more complex things. Video drivers can easily be the worst possible devices (especially if you're considering 2D/3D acceleration, shaders and GPGPU) and therefore should be left until last, and not done as soon as you can read data from disk.

Yeah I'm gonna write that driver as the last one because working on a video driver is just the waste of time and nothing more I can use text mode until I get a fully working graphics.

That's probably not a good idea either; because GOP (on UEFI) doesn't support text modes.

In general, the most sane method is to use firmware services to output characters very early during boot (e.g. either "int 0x10, ax=0x0E" for BIOS or the "EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL" on UEFI), then use whatever firmware provides to switch to a graphics mode that uses a linear framebuffer during boot (e.g. either VBE on BIOS or UGA/GOP on UEFI). After boot you'd use the (already setup) framebuffer, until/unless you load a native video driver.

Video drivers can easily be the worst possible devices; and NVidia are the worst possible video cards. There is no documentation, and most of the (open source) code you can find is derived from painful reverse engineering (and therefore likely to be dodgy and/or wrong anyway). Note: For setting video modes on Nvidia cards (and not everything else) you should be able to get enough information from open source projects (e.g. Nouveau).

So how linux initializes the highest resolution supported by video card? Does it use one of those open source projects? Or what about windows? Lets say windows XP or 98 which have very higher rendering speed than any other linux on my PC without the native drivers installed. I cant understand what they have done that they got this high rendering speed :O :O

These OSs have native drivers for almost all modern video cards, where the video card manufacturer writes the driver for their card. For ATI and NVidia on Linux (where the driver written by the manufacturer is a closed source/proprietary driver) there's also open source drivers as an alternative.

I'd recommend starting with something like CirrusLogic "CL-GD5446" (it's old and much simpler than modern cards, there's documentation online, and it's emulated by Bochs). Then I'd consider trying Intel's video (starting with their older stuff and working towards their most recent), partly because there's documentation for most of it and also open source code written by Intel, and partly because Intel's video has a higher market share than NVidia and ATI combined.

1 question. Does each video card model have its own driver and instructions? I dont mean the brand, just the model

It's possible to have a video driver that contains code for several video cards. This makes sense when the differences between them are minor (e.g. slightly different models, where 99% of the code is the same for both).

And I currently have Nvidia on my machine. If one day I write the intel's video card driver for my OS, am I able to use that driver on my machine with Nvidia video card???

If your driver is a massive thing that supports both Intel and Nvidia, then yes. In practice these video devices are very different, so it doesn't make any sense for the same driver to support both.


Cheers,

Brendan

[MadZarx]

That's probably not a good idea either; because GOP (on UEFI) doesn't support text modes.

In general, the most sane method is to use firmware services to output characters very early during boot (e.g. either "int 0x10, ax=0x0E" for BIOS or the "EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL" on UEFI), then use whatever firmware provides to switch to a graphics mode that uses a linear framebuffer during boot (e.g. either VBE on BIOS or UGA/GOP on UEFI). After boot you'd use the (already setup) framebuffer, until/unless you load a native video driver.

You mean I change to rmode to call BOIS instructions oh not again
I have heard about how easy it is to work with UEFI and call its functions in C. But my machine is an old one that have BIOS on a chip. So I can't support UEFI yet, ultil I buy a new laptop

These OSs have native drivers for almost all modern video cards, where the video card manufacturer writes the driver for their card. For ATI and NVidia on Linux (where the driver written by the manufacturer is a closed source/proprietary driver) there's also open source drivers as an alternative.

So the manufacturers write their video drivers for other OSs
I've seen some video drivers in linux kernel source which there was a dirver for Nvidia. Is that the thing that linux uses?

It's possible to have a video driver that contains code for several video cards. This makes sense when the differences between them are minor (e.g. slightly different models, where 99% of the code is the same for both).

If your driver is a massive thing that supports both Intel and Nvidia, then yes. In practice these video devices are very different, so it doesn't make any sense for the same driver to support both.

So the codes for different models are 99% same. I will just need something to change the resolution and enable 2D acceleration and nothing more But I'm sure it will be a hard job for me cuz I have no experience in writing video drivers
Is there a way to detect the video card brand and model? Like using something like cpuid?

[Brendan]

Hi,

That's probably not a good idea either; because GOP (on UEFI) doesn't support text modes.

In general, the most sane method is to use firmware services to output characters very early during boot (e.g. either "int 0x10, ax=0x0E" for BIOS or the "EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL" on UEFI), then use whatever firmware provides to switch to a graphics mode that uses a linear framebuffer during boot (e.g. either VBE on BIOS or UGA/GOP on UEFI). After boot you'd use the (already setup) framebuffer, until/unless you load a native video driver.

You mean I change to rmode to call BOIS instructions oh not again

No, I mean do this when you're still in the CPU mode that the firmware expects, before you switch to a CPU mode that the firmware doesn't expect. This means:

• for BIOS, setup a video mode while you're in real mode (before you switch to protected or long mode)
• for 64-bit UEFI, setup a video mode while you're in long mode (before you switch to protected mode, if its a 32-bit OS)
• for 32-bit UEFI (if you bother), setup a video mode while you're in protected mode (before you switch to long mode, if its a 64-bit OS)

Of course if you're using multi-boot, then you have no control over what happens before the boot loader starts your OS and have to use whatever the multi-boot boot loader provides (even if "whatever the multi-boot boot loader provides" is completely useless and broken).

I have heard about how easy it is to work with UEFI and call its functions in C. But my machine is an old one that have BIOS on a chip. So I can't support UEFI yet, ultil I buy a new laptop

Not really - most emulators support UEFI now (at least VMware, VirtualBox and Qemu do).

These OSs have native drivers for almost all modern video cards, where the video card manufacturer writes the driver for their card. For ATI and NVidia on Linux (where the driver written by the manufacturer is a closed source/proprietary driver) there's also open source drivers as an alternative.

So the manufacturers write their video drivers for other OSs
I've seen some video drivers in linux kernel source which there was a dirver for Nvidia. Is that the thing that linux uses?

Maybe. Video on Linux is a massive "cluster bork" with different pieces strewn all over the place (some in kernel, some in other places in kernel, some in different libraries like MESA, etc), where different pieces are used/unused depending on situation and kernel configuration. I'm not a Linux developer and probably wouldn't know if/when whatever you were looking at is used (even if I did know exactly what you were looking at).

It's possible to have a video driver that contains code for several video cards. This makes sense when the differences between them are minor (e.g. slightly different models, where 99% of the code is the same for both).

If your driver is a massive thing that supports both Intel and Nvidia, then yes. In practice these video devices are very different, so it doesn't make any sense for the same driver to support both.

So the codes for different models are 99% same. I will just need something to change the resolution and enable 2D acceleration and nothing more But I'm sure it will be a hard job for me cuz I have no experience in writing video drivers

My "99%" figure was not extremely accurate measurement, does not apply to all "slightly different models" and doesn't apply to any "very different models". How much variation there is between different models of one manufacturers video card depends on the specific models (e.g. there might be no difference at all between model xyz1234 and model xyz1235, but model xyz1235 and model 1236 might be very different).

Is there a way to detect the video card brand and model? Like using something like cpuid?

I think you need to forget about writing native video drivers until you've implemented some of the fundamental pieces of the OS that everything else relies on (including things like PCI bus enumeration, which will tell you the vendor and model of every PCI device).


Cheers,

Brendan

[MadZarx]

Hi,

No, I mean do this when you're still in the CPU mode that the firmware expects, before you switch to a CPU mode that the firmware doesn't expect. This means:

• for BIOS, setup a video mode while you're in real mode (before you switch to protected or long mode)
• for 64-bit UEFI, setup a video mode while you're in long mode (before you switch to protected mode, if its a 32-bit OS)
• for 32-bit UEFI (if you bother), setup a video mode while you're in protected mode (before you switch to long mode, if its a 64-bit OS)

Of course if you're using multi-boot, then you have no control over what happens before the boot loader starts your OS and have to use whatever the multi-boot boot loader provides (even if "whatever the multi-boot boot loader provides" is completely useless and broken).

So the only way that I currently can get graphics is using the VBE or GOP.

I have heard about how easy it is to work with UEFI and call its functions in C. But my machine is an old one that have BIOS on a chip. So I can't support UEFI yet, ultil I buy a new laptop

Not really - most emulators support UEFI now (at least VMware, VirtualBox and Qemu do).

Really? I didnt know that. I prefer Qemu because of its serial console But do these emulators have their own UEFI frimware?

These OSs have native drivers for almost all modern video cards, where the video card manufacturer writes the driver for their card. For ATI and NVidia on Linux (where the driver written by the manufacturer is a closed source/proprietary driver) there's also open source drivers as an alternative.

So the manufacturers write their video drivers for other OSs
I've seen some video drivers in linux kernel source which there was a dirver for Nvidia. Is that the thing that linux uses?

Maybe. Video on Linux is a massive "cluster bork" with different pieces strewn all over the place (some in kernel, some in other places in kernel, some in different libraries like MESA, etc), where different pieces are used/unused depending on situation and kernel configuration. I'm not a Linux developer and probably wouldn't know if/when whatever you were looking at is used (even if I did know exactly what you were looking at).

So lets just forget about the linux video driver

My "99%" figure was not extremely accurate measurement, does not apply to all "slightly different models" and doesn't apply to any "very different models". How much variation there is between different models of one manufacturers video card depends on the specific models (e.g. there might be no difference at all between model xyz1234 and model xyz1235, but model xyz1235 and model 1236 might be very different).

I got it now

Is there a way to detect the video card brand and model? Like using something like cpuid?

I think you need to forget about writing native video drivers until you've implemented some of the fundamental pieces of the OS that everything else relies on (including things like PCI bus enumeration, which will tell you the vendor and model of every PCI device).

So I should get infromation from PCI. I will implement it as soon as I learn it

Thank you dude and thank you all guys who helped me in this topic
I appreciate you guys

[Brendan]

Hi,

No, I mean do this when you're still in the CPU mode that the firmware expects, before you switch to a CPU mode that the firmware doesn't expect. This means:

• for BIOS, setup a video mode while you're in real mode (before you switch to protected or long mode)
• for 64-bit UEFI, setup a video mode while you're in long mode (before you switch to protected mode, if its a 32-bit OS)
• for 32-bit UEFI (if you bother), setup a video mode while you're in protected mode (before you switch to long mode, if its a 64-bit OS)

Of course if you're using multi-boot, then you have no control over what happens before the boot loader starts your OS and have to use whatever the multi-boot boot loader provides (even if "whatever the multi-boot boot loader provides" is completely useless and broken).

So the only way that I currently can get graphics is using the VBE or GOP.

The only way that you can (currently) get video to work reliably in all cases with minimum end user hassle, is to write the boot loaders yourself, and use VBE on BIOS and UGA/GOP on UEFI.

For an example; for a well designed OS, you can have a generic "live CD" where people download the image from your web site, burn it onto a CD and then boot it. This CD can contain boot loaders for BIOS and UEFI (where the firmware automatically uses the right boot loader); and those boot loaders can be designed to automatically select the best video mode that is supported by the video card, the monitor and the OS. Basically; you can ensure that video will automatically work in all cases with no end user hassle at all.

If you use multi-boot alone; you can get it to work "sometimes maybe if the end user is lucky" (with more hassles for end users, online "howto" documentation, plus a support site/channel/email address for all the people that didn't read the documentation, etc). For example, for a "live CD" you're mostly screwed because some end users will need to manually change GRUB's configuration just to get a video mode that works on their computer.

You could also use multi-boot with an "assume BIOS exists and switch to real mode to setup video with VBE" trick to make it more reliable, but then it will crash when the system is UEFI (and multi-boot won't tell you what the firmware was so you can't avoid that). You can't have a similar "assume UEFI exists and setup video with UGA/GOP" trick because the boot loader doesn't tell the OS where the UEFI's entry point is (and the boot loader will call the UEFI function to exit boot services anyway so GOP won't exist by the time the OS starts).

Not really - most emulators support UEFI now (at least VMware, VirtualBox and Qemu do).

Really? I didnt know that. I prefer Qemu because of its serial console But do these emulators have their own UEFI frimware?

Yes.


Cheers,

Brendan

[MadZarx]

Hi,

The only way that you can (currently) get video to work reliably in all cases with minimum end user hassle, is to write the boot loaders yourself, and use VBE on BIOS and UGA/GOP on UEFI.

For an example; for a well designed OS, you can have a generic "live CD" where people download the image from your web site, burn it onto a CD and then boot it. This CD can contain boot loaders for BIOS and UEFI (where the firmware automatically uses the right boot loader); and those boot loaders can be designed to automatically select the best video mode that is supported by the video card, the monitor and the OS. Basically; you can ensure that video will automatically work in all cases with no end user hassle at all.

If you use multi-boot alone; you can get it to work "sometimes maybe if the end user is lucky" (with more hassles for end users, online "howto" documentation, plus a support site/channel/email address for all the people that didn't read the documentation, etc). For example, for a "live CD" you're mostly screwed because some end users will need to manually change GRUB's configuration just to get a video mode that works on their computer.

You could also use multi-boot with an "assume BIOS exists and switch to real mode to setup video with VBE" trick to make it more reliable, but then it will crash when the system is UEFI (and multi-boot won't tell you what the firmware was so you can't avoid that). You can't have a similar "assume UEFI exists and setup video with UGA/GOP" trick because the boot loader doesn't tell the OS where the UEFI's entry point is (and the boot loader will call the UEFI function to exit boot services anyway so GOP won't exist by the time the OS starts).

So the best idea is to write my own bootloaders (Both for BIOS and UEFI). But how can BIOS find my bootloader image in an ISO file? I mean that 512 bytes of code inside a FAT image?