Writing SVGA Driver

[Tolga]

Hi.

I want to write svga driver. First of all, I want to change video modes and learn about modes. For these, what is processes? (I will continue to ask. )

Thanks.

[Brendan]

Hi,

I want to write svga driver. First of all, I want to change video modes and learn about modes. For these, what is processes? (I will continue to ask. )

First understand that video cards are complex. I'd recommend doing a "standard VGA" video driver, just to make sure you've got the basics sorted out (horizontal and vertical sync, VGA registers, video memory access/format, etc).

After this, I'd start with simpler/older cards and work up towards the more complex/newer cards. IMHO the best "next step" would probably be a Cirrus Logic "CLGD5446", because they are cheap, the programming documentation is still available, there's several sources of example code for it, and it is used by both Bochs and Qemu.

Also, the VESA VBE (BIOS) functions could be a much more sensible alternative - I'd probably do a generic VBE driver before worrying about doing any direct hardware control...


Cheers,

Brendan

[Tolga]

Yes thanks but i'm in pmode. So i dont have bios interrupts. To start, what do i need?

[bluecode]

Yes thanks but i'm in pmode. So i dont have bios interrupts.

It's possible to use BIOS interrupts in virtual-8086-mode.

[blip]

Before you switch to pmode you can do some VBE calls to find out the version and if there is a pmode interface available, and if so use that instead of switching to VM86 or real mode.
http://www.mega-tokyo.com/osfaq/How%20d ... %20mode%3F
http://vesa.org/public/VBE/vbe3.pdf

[Brendan]

Hi,

Yes thanks but i'm in pmode. So i dont have bios interrupts. To start, what do i need?

For VESA VBE, you can set up one SVGA video mode in real mode during boot, or for VBE 3.0 there's a protected mode interface that can be used to change video modes, etc while in protected mode. Unfortunately the VBE 3.0 protected mode functions are "optional", but it's better than the protected mode interface for VBE 2.0...

For direct hardware control you need the documentation for whichever card you're programming for. Programming for "standard VGA" hardware is another option, which should work for most cards (but not all, and it won't get you high resolution modes).

For standard VGA, you should be able to find references on the web (Google). Also, there was a DOS utility called "tweakVGA" around the web somewhere - it lets you see and set different VGA registers and can also generate C code for mode switches (including standard VGA BIOS video modes). It's worth looking for if you can run raw DOS...

For direct hardware SVGA drivers you need to know which chipset the card has and try to find documentation for it. The X11 source code (and maybe Mesa and other GPL code) might also help. I'd still recommend starting with standard VGA if you wanted to try direct hardware control though - things get even more confusing when you start trying to use more than 1 MB of video RAM, hardware mouse cursors, 2D/3D acceleration, etc...


Cheers,

Brendan

[Tolga]

Hmm. In pmode, I think using VBE3 functions are very useful. Is there any example about this? (Using V86 is hard for SVGA.)

[mhaggag]

Hmm. In pmode, I think using VBE3 functions are very useful. Is there any example about this? (Using V86 is hard for SVGA.)

You'd better not rely on VBE3 support--many cards don't have it. Additionally, I've seen people say the pmode interface support is sometimes there but broken.

[Tolga]

Is there any easy and good think to start to writing graphic driver? (Writing driver for each graphic driver is very hard. I think this maybe after 2 years )

[Pype.Clicker]

that's unfortunately a shame, but the only reliable method around is to use VBE's real-mode interface, either through VM86 monitor (there's an almost-ready-to-use implementation in OSlib), or by switching back in realmode for the video mode setting.

Virtually all other techniques will fail in some circumstance (too old hardware, buggy BIOS or whatever).

[distantvoices]

VBE, as Pype says, is the way to go.

[Tolga]

Which is faster the other? Is turning to Real Mode or using V86?

[Brendan]

Hi,

Let me try to put this into perspective...

First, let's use the term "class A video driver" to describe a video device driver that uses direct hardware I/O to support all of the features that a specific video card has. This is the sort of video driver you'd normally have for Windows.

IMHO "perfect" video support must involve a "class A" video driver for each video card. This is because users expect hardware accelerated 2D/3D and fancy graphics. Unfortunately, "perfect" isn't really possible.

The "best possible" video support must allow "class A" video drivers to be written, but must also have some generic video support for all of the video cards that don't have a "class A" driver. This is entirely possible.

To implement "best possible" video support you'd need to design a video driver interface, and code that can do everything in software if hardware acceleration isn't supported by the video driver. Then you need some generic video support. For the generic video support there's several solutions that all suck for different reasons.

The first solution is a protected mode VESA VBE video driver, which uses whatever protected mode video interface the video card's BIOS supports. As people have pointed out, this would be acceptable if the video card supports the optional functions in VBE 3.0, but may not be so good otherwise.

The next solution is a generic "standard VGA" video driver, which would work if the video card is compatible with standard VGA (most are) but won't support high resolution video modes.

Another generic solution is to use VBE and virtual8086. Personally I don't like it (it compilicates the kernel, and virtual8086 isn't supported in long mode).

Lastly, you can setup one video mode in real mode during boot, and have a "dummy framebuffer" video driver. This works well, but sucks because you can't change video modes without rebooting.

IMHO the best method is to provide all of these generic video options and support "class A" video drivers, and then let the user to decide which is best for their video card and their personal taste.


Cheers,

Brendan

[Brendan]

Hi,

Which is faster the other? Is turning to Real Mode or using V86?

For speed, real mode would execute the code a tiny bit faster but costs much more CPU time to enter and leave. IMHO speed is the least important thing though...

To switch back to real mode your code must be identity mapped. There's also problems delivering IRQs to the protected mode IRQ handlers while in real mode, which normally means interrupt latency gets trashed.

The easy way is to disable IRQs and let interrupt latency suck, but (in general) this doesn't work as real mode BIOS code expects to be in control of the entire computer and sometimes enables IRQs. You can't really mask the IRQs or remap them during mode switches, because this creates race conditions and/or lost IRQs.

The "best" way to do this is to map all of your IRQs to interrupt vectors that aren't used by the BIOS, and then have dummy IRQ handlers for real mode. When an IRQ occurs in real mode the dummy handler sets a flag, and when the CPU returns to protected mode the flags are checked and the real IRQ handler is called then. IRQ latency still sucks though.

Virtual 8086 mode solves these problems, but is painful to support (especially if you're writing a "lean" micro-kernel) and isn't support in 64 bit long mode.


Cheers,

Brendan

[Tolga]

Now, I decided to select video mode in boot and use it in pmode kernel. 1 or 2 years ago, i wrote a program in Turbo Pascal 7 for SVGA. And it is successful. I used bankswitching. But now i dont understand. In pmode, SVGA is using LinearBuffer. Now, if i want to use 1600x1200 32 Bit color, it uses 7 MB. Is this true?