VESA alternatives?

[animefreak1233]

I'm developing an OS with my friend. We've run into a wall. I really don't wanna use VESA (simply because of the VM thing, doesn't seem fun to do either).
I'd like to draw graphics, with access to high resolutions and writing to registers isn't a problem if enough documentation is available, since I've written code for microcontrollers, and no it wasn't arduino. Do you have any suggestions on what I could do?

[madanra]

What do you mean by "the VM thing"?

[Combuster]

If your opinion is that V8086 is already too difficult, just forget about high resolutions entirely.

[animefreak1233]

No, I just don't consider it 'elegant'. It feels kinda stupid to switch to 16bit mode every time I want to modify a little thing...

[animefreak1233]

What do you mean by "the VM thing"?

The v8086 mode

[iansjack]

You could study the open source Linux drivers for NVidia cards.

[animefreak1233]

what if I use qemu? How am I supposed to handle graphics on it?

[alexfru]

I'm developing an OS with my friend. We've run into a wall. I really don't wanna use VESA (simply because of the VM thing, doesn't seem fun to do either).

If you can stick to a fixed screen/color resolution, you can just set up the video mode of choice before entering protected mode and be done with it. This requires that the video card supports the linear frame buffer feature (you request it enabled when setting up the mode), otherwise you need to call into the VESA BIOS to choose which 64KB region of the video buffer you want to write to (640x480x8bpp is more than 4 such regions) and for that you will need some kind of emulation or virtualization if you intend to stay in protected mode.

[neon]

Hello,

Unfortunately, high resolution modes aren't well standardized. Your only options are VBE running in a virtual 8086 monitor or writing custom drivers for the devices that you would like to support. More options are available to the boot loader environment (depending on firmware; VBE, GOP, etc) so setting the video mode once during boot is a typical solution. However if you want control post-boot, you are limited to VBE and custom drivers - which is a shame given that VBE will probably be phased out soon.

You can get open drivers for Bochs, QEmu, and Virtual Box if you want to support high resolution on those devices. On real hardware however, you are pretty much limited to VBE, open standard devices and reverse engineering. QEmu implements the Cirrus Logic 5446 whose technical reference is available for free here (.gz file. The .pdf is inside of it.). Am sure you can find open source implementations of this device as well.

[madanra]

What do you mean by "the VM thing"?

The v8086 mode

You only need that if you're switching resolutions at run time. Simply setting the resolution at boot time before you switch to protected/long mode will be sufficient for a long time of OS development.

[mallard]

You could study the open source Linux drivers for NVidia cards.

If you're talking about VESA, you're clearly not doing 3D acceleration, so the large collection of "framebuffer" drivers in the Linux kernel covers >99% of all graphics cards ever released and they're not too hard to understand either.

Of course, the biggest issue with native graphics drivers for a small OS project isn't writing the drivers; it's testing them...

[SpyderTL]

what if I use qemu? How am I supposed to handle graphics on it?

http://qemu.weilnetz.de/qemu-doc.html

Code: Select all

-vga type 
Select type of VGA card to emulate. Valid values for type are 
   cirrus
        Cirrus Logic GD5446 Video card. All Windows versions starting from Windows 95 should recognize and use this graphic card. For optimal performances, use 16 bit color depth in the guest and the host OS. (This one is the default) 
   std
        Standard VGA card with Bochs VBE extensions. If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (>= 1280x1024x16) then you should use this option. 
   vmware
        VMWare SVGA-II compatible adapter. Use it if you have sufficiently recent XFree86/XOrg server or Windows guest with a driver for this card. 
   qxl
        QXL paravirtual graphic card. It is VGA compatible (including VESA 2.0 VBE support). Works best with qxl guest drivers installed though. Recommended choice when using the spice protocol. 
   tcx
        (sun4m only) Sun TCX framebuffer. This is the default framebuffer for sun4m machines and offers both 8-bit and 24-bit colour depths at a fixed resolution of 1024x768. 
   cg3
        (sun4m only) Sun cgthree framebuffer. This is a simple 8-bit framebuffer for sun4m machines available in both 1024x768 (OpenBIOS) and 1152x900 (OBP) resolutions aimed at people wishing to run older Solaris versions. 
   virtio
        Virtio VGA card. 
   none
        Disable VGA card.

Pick which type of hardware you want to support, and write a driver for it. I would recommend using "vmware" if you are going to be running in 32-bit or 64-bit mode, since the procedure for changing the display mode, directly, is well documented. No need for switching back to 16-bit or setting up v8086.

"virtio" has piqued my interest, but I haven't found any real documentation for it, yet...

[animefreak1233]

Thanks. I never thought I'd get these many answers. Guess I've got no other choice but to implement VESA... (still, it sucks)

[Brendan]

Hi,

Thanks. I never thought I'd get these many answers. Guess I've got no other choice but to implement VESA... (still, it sucks)

VESA/VBE doesn't suck - it's far worse than that!

The problem is that for most video cards VBE doesn't care if the monitor supports a video mode or not; so you can set a video mode that is completely useless without knowing it. To guard against this you need to compare the video mode timing for each mode to the video mode timings that the monitor says it supports (via. EDID).

The problem with that is VBE doesn't tell you the video mode timing for each video mode. For example, there are an almost infinite number of possible 800*600 video mode timings (each with different sync pulse polarities, sync pulse widths, front/back porch times, frame rates, etc); and about 5 relatively common 800*600 video mode timings (with different frame rates - 60 Hz, 75 Hz,80 Hz, ...); and a monitor might support some 800*600 video mode timings and not others; and VBE will just tell you "800*600".

Basically; to ensure that you're setting a video mode that the monitor supports you need information that VBE doesn't provide, and to work around that your only option is to use an ugly heuristical approach to estimate the probability that a video mode might work. For example, for an 800*600 mode you might see how many of the common 800*600 timings the monitor supports, and determine how many are within the monitor's frequency limits, and if the monitor supports (GTF/CVT) "variable timings"; and calculate a "probability that this unknown video mode timing is something the monitor supports" based on that.

Note that for VBE 3.0 they added the ability for software to provide a "CRTC info block" structure when setting a video mode, and by using this you can force the video card to use a specific video mode timing that you know the monitor does support. You can also use this to make more video modes. For example, if the video card says it supports "800*600 with unknown timing" you can use "CRTC info block" to create 800*600@60Hz, 800*600@75Hz, 800*600@80Hz, etc; and (with pixel/line doubling) also create 400*300, 400*600 and 800*300 variations; and end up with maybe 12 different variations (where each one uses a timing that the monitor says it supports). Of course this assumes that the video card's support for "CRTC info block" structure isn't buggy; so in reality you just end up with a lot more video modes where the "probability the video mode works" is based on how buggy you think the video card's "CRTC info block" support is (instead of how likely it is that the monitor supports the video mode timing).


Cheers,

Brendan

[mallard]

Basically; to ensure that you're setting a video mode that the monitor supports you need information that VBE doesn't provide, and to work around that your only option is to use an ugly heuristical approach to estimate the probability that a video mode might work. For example, for an 800*600 mode you might see how many of the common 800*600 timings the monitor supports, and determine how many are within the monitor's frequency limits, and if the monitor supports (GTF/CVT) "variable timings"; and calculate a "probability that this unknown video mode timing is something the monitor supports" based on that.

While this may work for you, this definitely falls under "too clever for its own good" in my book. It might be useful to do this for setting an initial resolution for the OS's installer (although setting an "virtually certain to be safe" mode such as 640x480 or falling back to a text-based UI is probably sufficient for an OS installer), but after that, the "ask the user if they can see the screen" method is both accepted by users and will work in cases when your heuristic fails (such as when EDID is unavailable).