OSDev.org

I'm writing an operating system in C and I'd like to know how to use VESA in C. The tutorials aren't really helpful when it comes to sample code.

Thanks.

~Osmium USA

Can you please expand on what you mean by VESA? AFAIK, VESA is a standards body, do you maybe mean VGA?

This contains a nice example of VGA text mode:
http://www.few.vu.nl/~herbertb/misc/basickernel.pdf

Once, you've got started with VGA text mode, you can read this, to get graphics going.
http://wiki.osdev.org/VGA_Hardware

On the other hand, if all you are doing is dumping text (which is more than enough for a LONG time on a personal kernel project) then I can show you how to get a serial port working and configure qemu to show this.

Sorry. I'm used to refering to SVGA as Vesa.
~Osmium USA

Hi,

osmiumusa wrote:Sorry. I'm used to refering to SVGA as Vesa.

Your choices are:

• Write native drivers for each different type of video card (some of which are undocumented)
• Use the VESA/VBE protected mode interface that was introduced in VBE 3.0, that isn't supported by any older video cards video cards and isn't supported by most VBE 3.0 video cards either
• Use the VESA/VBE real mode interface

Obviously the first choice isn't very practical. If you ever manage to write a video driver for every video card end-users will still have no video support sometimes because when a new video card is released it'd take time for someone to write the driver (e.g. if NVidia release a new video card next week, then end-users who buy it won't be able to use it for several months).

The last 2 choices won't support 2D/3D acceleration or anything more than a "framebuffer" interface; won't work for dual-monitors; and won't support all video modes that the video card is capable of (e.g. typically you get 4:3 modes and don't get any 16:9 or 16:10 modes).

Of course if your OS is for protected mode and/or long mode you can't use the real mode interface directly. In this case your options are:

• Setup a video mode during boot (e.g. before you switch to protected mode or long mode). If the user wants to switch video modes after boot then they either need a native video driver or they need to reboot.
• Use Virtual8086 mode (can be messy, and doesn't work for long mode)
• Implement (or port) some sort of "real mode emulator" (even more messy than Virtual8086 mode, but works in long mode)
• Use hardware virtualisation - very messy (different code for AMD/SVM and Intel/VMX, where I think VMX needs to use Virtual8086 inside the virtual machine to run real mode code). This doesn't work on CPUs that don't support SVM or VMX.
• Temporarily switch back to real mode, which is difficult to do reliably without causing major problems for IRQ handling (for all possible IRQs you need to install real mode stubs which switch back to protected/long mode and run the real IRQ handlers)

For a hobbyist OS, it won't matter much what you do, so I'd use the "set a video mode during boot" option (as it's the least amount of work).

For a good quality OS your long-term goal must be native video drivers, as that's the only way to support the features that users expect. In this case you'd also need to support some sort fall-back option (for when there is no native video driver). For the fall-back option the user won't be satisfied regardless of what you do; so there isn't much point wasting too much time on it, and I'd use the "set a video mode during boot" option (as it's the least amount of work). This isn't as simple as it seems at first - to support native drivers your video driver interface has to expect the video driver to do all the drawing (so it can be accelerated), which means that your "framebuffer" fall-back driver (which needs to use the same video driver interface) also needs to do all the drawing. Basically you end up implementing a software renderer for the "framebuffer" driver (that imitates the features of hardware accelerated 2D/3D); and parts of this software renderer might also be used by native video drivers for low-end video cards that don't support some features.


Cheers,

Brendan

osmiumusa wrote:I'd like to know how to use VESA in C.

You can not use VESA VBE from C. It's a real mode assembly interface. I see Brendan gave a fully rephrased version of the FAQ page on the subject, but most likely you want to either use GRUB to do the dirty work of setting a video mode, or not use VBE and write a VGA driver: they are the fastest way to get into a working graphics mode.

V8086 (hardware) and software emulation are by general consensus the best way into a VESA mode, but they are also more elaborate and therefore much more demanding on the rest of your system, and my crystal ball suggests you're not quite there yet. And at the far end, writing a plethora of graphics drivers is pretty much reserved for the nutcases like yours truly

OK. So then from C, in simplest terms, how do I set a SVGA mode and print a pixel - using GCC inline assembly or otherwise. I've gotten basic IN/OUT functions on my OS to work. But I'd like to move into graphics.

~Osmium USA

Hello,

osmiumusa wrote:OK. So then from C, in simplest terms, how do I set a SVGA mode and print a pixel - using GCC inline assembly or otherwise. I've gotten basic IN/OUT functions on my OS to work. But I'd like to move into graphics.

If you want to stick with using C, either add support for v86 tasks and use VBE, or find the specification for your video card and build an implementation to support it. Sorry, but it doesnt get much simpler, and both solutions require a bit of support code.

The only alternatives is to set the VBE mode before going into protected mode or scrapping supporting SVGA modes, and just use standard VGA.

Combuster wrote:

osmiumusa wrote:I'd like to know how to use VESA in C.

You can not use VESA VBE from C. It's a real mode assembly interface. I see Brendan gave a fully rephrased version of the FAQ page on the subject, but most likely you want to either use GRUB to do the dirty work of setting a video mode, or not use VBE and write a VGA driver: they are the fastest way to get into a working graphics mode.

V8086 (hardware) and software emulation are by general consensus the best way into a VESA mode, but they are also more elaborate and therefore much more demanding on the rest of your system, and my crystal ball suggests you're not quite there yet. And at the far end, writing a plethora of graphics drivers is pretty much reserved for the nutcases like yours truly

This is NOT entirely true Combuster, the VBE setup is required to be in RM assembly yes, but, once you have it initialized, and have a pointer the the video memory, C is not unrealistic to use.

Setup a video mode during boot (e.g. before you switch to protected mode or long mode). If the user wants to switch video modes after boot then they either need a native video driver or they need to reboot.

< This is how i do it aswell, my bootloader handles the RM VBE interface. But since i run in longmode... switching to PM then to V86 is a real pain. So the reboot option works well.

I think what your actually asking, osmiumusa, is how to change res then access the screen...?

iLewis wrote:

Combuster wrote:

osmiumusa wrote:I'd like to know how to use VESA in C.

You can not use VESA VBE from C. It's a real mode assembly interface. I see Brendan gave a fully rephrased version of the FAQ page on the subject, but most likely you want to either use GRUB to do the dirty work of setting a video mode, or not use VBE and write a VGA driver: they are the fastest way to get into a working graphics mode.

V8086 (hardware) and software emulation are by general consensus the best way into a VESA mode, but they are also more elaborate and therefore much more demanding on the rest of your system, and my crystal ball suggests you're not quite there yet. And at the far end, writing a plethora of graphics drivers is pretty much reserved for the nutcases like yours truly

This is NOT entirely true Combuster, the VBE setup is required to be in RM assembly yes, but, once you have it initialized, and have a pointer the the video memory, C is not unrealistic to use.

You are implying that modifying the video memory using C is equal to using the VESA VBE interface.


Regards,
Stephan J.R. van Schaik.

StephanVanSchaik wrote:

iLewis wrote:This is NOT entirely true Combuster, the VBE setup is required to be in RM assembly yes, but, once you have it initialized, and have a pointer the the video memory, C is not unrealistic to use.

You are implying that modifying the video memory using C is equal to using the VESA VBE interface.

Not to mention that the above is only true for modes that support a LFB. If not you would still need to use the VBE interface from within your C code.

neon wrote:

StephanVanSchaik wrote:

iLewis wrote:This is NOT entirely true Combuster, the VBE setup is required to be in RM assembly yes, but, once you have it initialized, and have a pointer the the video memory, C is not unrealistic to use.

You are implying that modifying the video memory using C is equal to using the VESA VBE interface.

Not to mention that the above is only true for modes that support a LFB. If not you would still need to use the VBE interface from within your C code.

Yes you are correct, that is my mistake. I need to remember not everyone lives in the future...

I guess what you are looking for, at this stage, is switch to high resolution true color mode and then plot pixel on it . Plotting pixel is quite simple once you initialize the mode you want. And this can be done entirely in C once you are set to use the linear frame buffer. The wiki has a good explanation about this . Unfortunately, setting up the appropriate mode has to be done while in real mode. If you are using GRUB you can configure it to do this job for you but if you are using custom bootloader, you need to manually do this. There are alot of VESA tutorial available in the web so get one and get going. And of course, for simplicity here's what you need to do:
1 Check to see if VESA 2.0 interface exist.
2 Search the mode you want. Check to see if this mode supports LFB. If it doesnt, find the mode which does.
3 Save the address of LFB. You need to pass this address to the kernel.
4 Set the mode you find appropriate. Set bit 14 to use the LFB.

All done. You can now throw pixel at the address of LFB from within the C code.
And of course, at this stage, if you are thinking about the alternative such as Specific video card driver or Virtual8086 mode, get ready to struck your head in the wall.


Best regards,
Chandra

How do you configure grub to do this?

~osmiumusa

See the Multiboot Specification.

GRUB legacy doesn't support the video mode aspects of multiboot without a patch, IIRC.