OSDev.org

Hi!
How to choose video mode (graphics) that suits one's monitor best?
For example, when windows is being installed it suggests to set the optimal video mode (in Win's opinion). Are there any standards on "what is optimal"?
I want to implement this "optimal video mode" idea in my OS so that the appropriate mode will be set for 15" CRT and for 21" Widescreen LCD, for example.
If possible, it should not require any special drivers, just standard BIOS functions or I/O...
Please, help, men!

below 13": 640x480 or 320x200 (VGA mode, if it's really ancient)
14" monitor: 800x600
15" monitor: 1024x768
17" monitor: 1280x1024

altough resolutions higher than 1024x768 makes my eyes hurt even on 75Hz refresh rate on LCD.

IIRC, winxp will just go to 1024x768 if that's available.

And with "basic" code you won't get to know much (i.e. nothing) about your monitor to make a more educated decision than that. All you can get is what the video card can do.

is it possible to somehow get the information about a CRT (and LCD) display? For example, supported resolution, screen refresh rate, vendor, etc. May be you could give me some links where to start from?

Hi,

zhak wrote:How to choose video mode (graphics) that suits one's monitor best?

For modern monitors it's possible to get information about what the monitor supports - see the Wikipedia page for Extended Display Identification Data (and the link to "VESA BIOS Extensions/Display Data Channel Standard" near the bottom of the page).

Note1: For some monitors (like LCD monitors) there's *one* native resolution. All other resolutions are scaled by the monitor into the native resolution. This typically gives poor quality results due to fast scaling algorithms (no dithering) and quantumising effects. For example, the monitor I'm using now has a native resolution of 1680 * 1050; and "normal" video modes (640*480, 800*600, 1024*768, etc) all look ugly because they aren't a multiple of the native resolution (like 840 * 525 would be).

Note 2: If the monitor doesn't support EDID (or if your software doesn't support EDID), then 800 * 600 is the highest you should go because there are older "standard VGA" monitors that can't handle higher resolutions and blow up - this is not a joke or a myth! Blowing up people's hardware isn't nice; even if the hardware is so old that it deserves to be blown up...

Excluding both of these notes, I'd be tempted to invent some sort of formula that calculates a score or rating for each available video mode (and then select the video mode that got the highest score/rating). The calculation could take into account the computer's RAM, the video card's RAM, the monitor size, etc.


Cheers,

Brendan

Thanks a lot! This is very helpful!
But again I've got much more questions...
I've read some VESA documents (which I could find) on the topic. So, to get EDID VESA Function 4F15h Int 10h should be invoked. Ok. But what if it's not supported by BIOS? How to read EDID then? And how this info can be retrieved when in protected mode? For example, one switches from one display to another without turning the PC off (or just wants to test hardware). The new information should be read then...
I'm sure the display controller can be accessed with i/o ports, but I still can't find any objective information about it. still googling.....

I've found a small program DumpEDID for WinXP. Tried to run it under debugger, but didn't get much at a glance. It seems that it uses information from registry. It shows info about two displays: a new (LCD) one, and an old CRT, which I didn't use for ages.

in Pmode, you have only one option: implement multitasking, then make a v86 driver that generates int's by creating a v86 task. i think linux kernel 1 has this. Check it out;)

in Pmode, you have only one option

False.

1) Use VM8086, you need to have multitasking implemented.
2) Make routines to switch to real mode and back (I use this).
3) Control the graphics adapter using I/O. AFAIK you can't control VESA VBE that way.

Again, looking at the Linux source code... well you heard me in previous topics, I think there's no need to repeat myself. (If somebody missed it, just pm me and I'll sort it out quickly for you: Brendan explained to you more efficently than some linux source would.)

ok, that's true, i should say the best: realmode is not so good or simple to use, and with i/o u'll need to find some advanced documentation and will give some headcaches.

I'm not sure about all.
And linux kernel source has v86 implemented. i wanted to say that would be an example

sorry

Thanks, I'll check linux sources for sure. I'm sure some more questions will arise after that. ...Things become more and more complicated every next day

realmode is not so good or simple to use

You sure 'bout that? Do you know what's a real mode and did you use it sometimes?
Yes, if you want to program a specific graphics card using port I/O, you need to study every card's internals (e.g. you can't use the same hardware acceleration functions on geforce4 and nvidia 8800), but the VGA standard uses declared ports (not for hw accel, but for displaying in general). VESA VBE uses bios functions but they are a standard, too.

On the other side you can't make amazing HW 3D accelerations neither with VGA (320x200) or VESA. In that case you need to program every graphics driver for every graphics card.

//EDIT: Just for the real mode bit, if you are programming your own OS in real mode, you have the disk, video and keyboard driver ready and totally bug-free through ROM-BIOS. Rmode quickly fell out of favor because of it's memory managment (segment:offset), 64K segments limit (unreal mode could fix this, but only for data segments) and only 640K of memory (actually only segments 0x0050 to 0x9FFF could be only used), and because the ROM-BIOS functions were synchronous. For example in DOS when you performed the COPY command, you couldn't do anything else (or in windows 95: W95 used in floppy disk transfer the virtual 8086 mode and you couldn't do much when eg copying files, either.)

MS-DOS responded to the memory limitation. If you grew up on MS-DOS/Windows 9x or 3.x, you surely know about HIMEM.SYS or "expanded memory manager". DOS had some kbytes reserved at segs 0x50 to 0x6F and it started loading programs or TSRs at 0x70, or the so-called "HMA" (unreal mode part), then it copied the code back to 640K boundary, since you cannot execute in realmode anything that is more than 640K in size and lies above 1MB. For MS-DOS, a maximum executable size to load was something at 500K, depends on your free memory.

Using unreal mode ("HIMEM.SYS" as in DOS) gives you full access to max. 4 GB of RAM, but only for storing data. You couldn't execute code above the 1MB boundary again. DOS used code-copying and it relocated three quarters of its kernel above 1 MB (if it would be possible) and leaved only it's ISR handling functions (INT 21h etc) for programs. Then it loaded the program from the HMA to "conventional memory", the 640K part and began execution.

Just for clarification.

Hi,

zhak wrote:So, to get EDID VESA Function 4F15h Int 10h should be invoked. Ok. But what if it's not supported by BIOS? How to read EDID then?

There's 3 different cases here - the "read_EDID" function not supported by the video card's ROM, the ability to read the EDID not supported by the video card, and the EDID not supported by the monitor. All three of these are possible (depending on age and quality of each part).

Basically , if you can't read the EDID for *any* reason, then you need to assume that the monitor is old and choose a video mode that an old "standard VGA" monitor can handle.


Cheers,

Brendan