OSDev.org

Hi,

Note: This post is a rant, not a question. I put it in this forum because it might contain information that's useful for other OS developers (or more likely, it might be a useful warning to anyone who's thinking of attempting something similar )...

I'm trying to write code that detects usable video modes during boot. Sounds fairly simple doesn't it?

The problem is that little word in the middle - "usable". The video mode needs to be supported by the monitor, and if it's not supported by the monitor it shouldn't be in my list of usable video modes; mostly because the OS automatically selects a video mode from this list and the user can't change to a different video mode unless they can see what they're doing.

Also, I only care about colour graphics modes - 4 bits per pixel planar graphics modes, and 8/15/16/24/32 bits per pixel graphics modes (I have no intention of supporting text mode or strange pixel formats like YUV, etc). If I can't find a usable graphics mode then there's no video after boot.

The saga begins here...

There was some ancient video cards and monitors - EGA, MCGA, CGA, etc. I'm not too concern about these, but I can use "Int 0x10, AX = 0x1A00" to determine which video modes the video card and monitor support. For old EGA video cards I can still support "320 * 200 * 16 colour" and "640 * 200 * 16 colour" video modes. For VGA I can support these same modes plus "640 * 350 * 16 colour", "640 * 480 * 16 colour" and "320 * 200 * 256 colour" video modes. For anything else (CGA, MCGA, etc) I'll give up with a "the video hardware isn't supported" message.

Next comes VGA/SVGA. For some old VGA and SVGA monitors it's possible to blow up the monitor by exceeding it's horizontal and/or vertical scanning frequency. For these monitors you're screwed - software has no way to figure out what the monitor supports (and if you're like me, the end user has lost the booklet that came with the monitor and has no idea either). Some old VGA and SVGA monitors don't blow up. However there's still no way to determine if a video mode is usable or not.

To fix this problem VESA introduced DDC (Display Data Channel) and EDID (Extended Display Identification Data). DDC is a hardware protocol (e.g. like RS232) that allows the monitor to talk to the video card. EDID defines the format of the data that the monitor sends to the video card. The entire purpose of EDID is to tell the video card what sort of monitor is connected and which video modes are supported. VESA also added a BIOS function that software can use to read the EDID from the monitor ("Int 0x10, AX=0x4F15, Bl=0x01").

I decided that if I can't get EDID then I can't assume that the monitor supports more than standard VGA resolutions, and I can only allow standard VGA video modes.

I also assumed that if I can get EDID then other software can also get EDID; and that VBE would use EDID for it's intended purpose - to prevent VBE from being used to set video modes that the monitor can't support. I was entirely wrong. For VBE, most (all AFAIK) video cards completely ignore EDID.

So what do I do now? I've got code to load all the EDID information into RAM, and I'm planning to use this information to restrict the list of modes returned by VBE so that only video modes that are supported by the monitor will end up in my list of usable video modes.

However, a video mode is more than just the horizontal and vertical resolution - there's also horizontal and vertical frequencies to worry about. For example, a monitor might support 1024 * 768 @ 60 Hz but might not support 1024 * 768 @ 70 Hz. The "Return VBE Mode Information" function only tells you what resolution (and colour depth) the video mode is but does *not* tell you what refresh rate you'll get; and therefore you've still got no way of knowing if the monitor supports the video mode.

For VBE version 3.0, the "Return VBE Mode Information" function will tell you the maximum pixel clock frequency for the video mode, which can be used to estimate the maximum vertical refresh rate you could end up with. That information is mostly useless because you still don't know the default pixel clock frequency (to allow you to estimate if the vertical refresh rate is supported by the monitor) and you still don't know the minimum pixel clock (to see if the entire range of possible vertical refresh rates are supported by the monitor).

For VBE 2.0 or later, you can pass a "CRTCInfoBlock" to VBE when you set the video mode (e.g. in an attempt to make sure the timings end up within the range supported by the monitor), but VBE chooses the closes frequency it supports and there's no way to tell if the closest frequency VBE supports is within the range of frequencies supported by the monitor, and no way to do this without setting the video mode first (and setting 50 different video modes during boot, one after the other, would look a little crappy - it might make the end user think the monitor is having an epileptic fit).

For VBE 3.0, Function 0x0B lets you get and set the pixel clock for any VBE video mode. This could be used to check if the video mode can be setup with timings that the monitor supports. This actually does sound like an answer to me (although it's a complex messy answer involving strange calculations and estimates based on other information that may or may not be present).

Finally, there's always bugs to consider. There's no guarantee that the video card's ROM and the monitor's EDID aren't full of bugs. Some OS's have a database of "corrected EDID", where the monitor's identification (PnP ID) is used to find out if there's replacement EDID information to use. Also, for some video cards I've seen reports that EDID may or may not work depending on where it's plugged in (e.g. if the monitor is connected to the video card's analogue/VGA connector then EDID works, but if the same monitor is connected to the same video card by the DVI connector instead then EDID doesn't exist).

To be honest, I'm tempted to dump all this mess and only allow standard VGA video modes. Unfortunately I know there won't be any native video device drivers for my OS for a very long time, and people just don't like using "640 * 480 * 16 colour" video mode when their hardware supports much better video modes.

*sigh*


Cheers,

Brendan

I have also tried to correct timing mode by VESA GTF, but it's all fake, the video card manufacturers does not take into account VESA for a long time,
Why prefer to give their drivers more or less functioning, show only the information more or less standard as the BIOS, for example, I always had the impression that the BIOS is a copy and paste of AT BIOS, with some additions for the new chipset,
I do not trust either of the function AX = 1A00H.
We would like a committee that controls whether the BIOS, VESA, and so on are compatible, otherwise it should not be allowed under certain cards, or firmware to be sold

I am sorry to say Brendan, that your post is a good example of why many OS Dev's end up making very little progress.
You are trying to do your best for the general user, but in end give them no choice at all.
So your best just post the available mode that the card can give, but add a big warning, Use at your own risk!

Hi,

Dex wrote:I am sorry to say Brendan, that your post is a good example of why many OS Dev's end up making very little progress.

You're right about that - I spent all yesterday playing (testing?) a game called Vega Strike because I didn't want to look at my code. Today was my Grandmother's 80th birthday - I haven't looked at my code since I created this topic. I have been thinking about it though...

I've got a "boot script", which is mostly just a text file consisting of "<variable> = <value>" lines. My current thoughts are to use a boot script variable to control the behavior of the boot code, where "defaultVideoLimit = 0" means the boot code should only allow standard VGA video modes, "defaultVideoLimit = 1" means only video modes that *should* work are allowed, and "defaultVideoLimit = 2" means all video modes are allowed (e.g. ignore EDID). On top of that I'll have boot script variables for each video mode that modify the "defaultVideoLimit" setting's behavior - for e.g. "videoMode800x600x4 = 0" would disable all 800 * 600 * 4 bpp video modes and "videoMode1024x768x32 = 1" would allow all 1024 * 768 * 32 bpp video modes.

When the OS is first booted (e.g. when the OS is about to be installed) the boot script will contain "defaultVideoLimit = 0". If a suitable native video driver is found it can change the values in the boot script (and change the video mode itself), and if no video driver is found the end-user can change the values in the boot script instead. Then the modified boot script will be installed with the rest of the OS ready for the next time the OS is booted, which means that (normally) the end-user would only be stuck with the 640*480 4 bpp video mode if there isn't a native video driver and then only until the OS is installed and rebooted.

It also means that my list of usable video modes is no longer a list of usable video modes - it needs to become a list of all possible video modes, including a field that says what the "defaultVideoLimit" would need to be set to for the video mode to be allowed.

Of course this still means I need to parse EDID and check if VBE video modes are usable or not (according to EDID). However, there's a large difference between checking if a video mode should be usable (e.g. "from the information I've gathered it's likely that this video mode should work if you're lucky") and checking if a video mode is definitely usable (e.g. "from the information I've gathered I can guarantee without any doubt that this video mode will work perfectly")...


Thanks,

Brendan

The solution to all this is simple: lose the nerdy mindset, and think what an actual user would need. Any user, yes, any user, with a PC old enough to have a monitor attached that cannot handle the VESA modes of the video card, let alone break when getting the wrong resolution/timing, is a very experienced old-computer hobby geek. For the simple reason that we're talking PCs from the early 90s or late 80s (earlier and they don't even have EGA, so you don't support them anyway). [There's probably some simple test for this: real 386? -> be very careful (probably fixed sync or early multi-sync monitor), 486? -> also be carefull, although multisync probably attached, Pentium and up? very probably multi-sync monitor, especially if Pentium with PCI video card.]

So, you can simply offer what VESA tells you, with a warning saying older PCs/monitors may have a problem, and any non-geek user is ok since his monitor will definitely not break from setting any VESA mode (he'll have a TFT anyway), and all other users (which, face it, will be the only users of your OS for a loooong while) are geeky enough to know what mode to choose.

You really are seeing problems where there aren't any :).


JAL

Hi,

I agree with Jal. I really admire the way that you always try to take every eventuality in to account and the fact that you are pedantic about the hardware testing, but I think that the last thing you need to be worrying about is the fact that you know 1024*768 is supported, but do not know what refresh rates are available.

Anyone using an "alternative OS" knows enough to realise whether they have an explodable monitor or not. By the time your OS goes mainstream, you will have native video drivers and a team of developers anyway

Cheers,
Adam

(and if you're like me, the end user has lost the booklet that came with the monitor and has no idea either)

There's usually a white sticker on the back that gives the maximum refresh rate in a tiny font.

Hi,

AJ wrote:Anyone using an "alternative OS" knows enough to realise whether they have an explodable monitor or not. By the time your OS goes mainstream, you will have native video drivers and a team of developers anyway

I'm wondering if anyone took a look at Vega Strike (the game I mentioned briefly earlier). Every 6 months or so I check on this game to see if it's progressed much, and each time I walk away with the same impression - "nice graphics, pity about all the glitches". They're struggling to attract developers, and without developers progress is extremely slow.

For my OS, there's potential glitches that I could do something about (like video mode handling during boot). There's also potential glitches I won't be aware of. If the number of glitches is too high then it'll be very difficult for my OS to become accepted as more than just a hobby OS, and it'll be difficult to attract developers once the kernel, etc is ready. Because of this, IMHO fixing the potential glitches that I am aware of is extremely important...

@Craze Frog: I took a look behind one of my monitors - it's got maximum horizontal frequency and maximum vertical frequency, but not maximum resolution...


Cheers,

Brendan

Brendan wrote:For my OS, there's potential glitches that I could do something about (like video mode handling during boot). There's also potential glitches I won't be aware of. If the number of glitches is too high then it'll be very difficult for my OS to become accepted as more than just a hobby OS, and it'll be difficult to attract developers once the kernel, etc is ready. Because of this, IMHO fixing the potential glitches that I am aware of is extremely important...

You are no doubt well aware that your OS will probably never be more than just a hobby OS, so I won't venture into that discussion. What I will say however, is that it seems you are living under a rock without knowing what happens in the real world. People that want to try your OS will use it in an emulator or virtual machine. Providing an ISO image that can run in VMware et al and runs in that without glitches is very important. Supporting old junk is definitely not. Nobody will care. You'd better focus on the important stuff, instead of spend months (years?) on completely useless support. You really think you can ever progress enough, and atract other developers, if you have the very, very basics, but support all 150 varieties of VLB cards? Of course not. You are far better off when you only support P4+, non-accelerated VBE 2.0 with LFB and ACPI and having a decent set of OS features, running without glitches in the top-3 virtual machines, than trying to make the system compatible with every known version of the Intel 32-bit processor, ISA and VLB graphics cards and plain BIOS. It's a real pitty you don't see it that way, as we all know you otherwise don't lack common sense and a brain.


JAL

Brendan wrote: @Craze Frog: I took a look behind one of my monitors - it's got maximum horizontal frequency and maximum vertical frequency, but not maximum resolution...

I didn't say it would show the resolution, did it? I don't think you can fry them with too big resolution, only frequency. Am I wrong?

Craze Frog wrote:

Brendan wrote: @Craze Frog: I took a look behind one of my monitors - it's got maximum horizontal frequency and maximum vertical frequency, but not maximum resolution...

I didn't say it would show the resolution, did it? I don't think you can fry them with too big resolution, only frequency. Am I wrong?

If you have the maximum HFreq and minimum VFreq, you can compute the maximum amount of scanlines your monitor theoretically supports. If you know the scanline count, you can determine the vertical resolution by subtracting the VBlank range, and next the horizontal resolution based on a worst case aspect ratio.

But agreed, that's only an approximation.

Hi,

Craze Frog wrote:

Brendan wrote:@Craze Frog: I took a look behind one of my monitors - it's got maximum horizontal frequency and maximum vertical frequency, but not maximum resolution...

I didn't say it would show the resolution, did it? I don't think you can fry them with too big resolution, only frequency. Am I wrong?

I think the main thing that kills old monitors is too fast horizontal frequency, but it's hard to find good information on the exact cause.

Fixing the "blowing up the monitor" problem (which is probably rare now - I'd guess a large percentage of these monitors have been blown up already or thrown away for other reasons) would still leave the "user can't see anything except flickering lines of snow and decides my OS is crud" problem (which is still very likely, even for new hardware where the monitor was bought at the same time as the computer).


Cheers,

Brendan

Just to kick in some real life idea (MS is good for something after all)

"The system will now change the resolution. If the monitor does not support the resolution it will be changed back after 15 seconds"

Make from that what you want

Brendan wrote:I'm wondering if anyone took a look at Vega Strike (the game I mentioned briefly earlier). Every 6 months or so I check on this game to see if it's progressed much, and each time I walk away with the same impression - "nice graphics, pity about all the glitches". They're struggling to attract developers, and without developers progress is extremely slow.

Haha, I had an early version of Vega Strike once when the graphics were really crappy. Haven't tried since then, might want to download it again!

Combuster wrote:Just to kick in some real life idea (MS is good for something after all)

"The system will now change the resolution. If the monitor does not support the resolution it will be changed back after 15 seconds"

Make from that what you want

Most good GUIs do that, like Gnome, Mac OS X (IIRC), xfce, etc.

Hi,

Combuster wrote:Just to kick in some real life idea (MS is good for something after all)

"The system will now change the resolution. If the monitor does not support the resolution it will be changed back after 15 seconds"

Make from that what you want

Hehe. That only works if you make assumptions about input devices (it's followed by a "Did it work? [OK] [Cancel]" dialog box, where you have to select "OK" within 15 seconds). I'm not willing to make those sorts of assumption in my boot code - there could be just a touch screen and joystick, or maybe a microphone (for speech recognition) or maybe 6 different keyboards; and if I built device drivers for all of these into the boot loader then there's still no guarantee that the computer has any input devices at all.


Cheers,

Brendan