Retrieve display monitor capabilities

[kanageddaamen]

Hello all,

I have found the wiki and this forum extraordinary helpful on my adventure into the world of OS development. However, looking through both this site and the wider googleverse I have been unable to find the answer to a question I have.

In the kernel I am developing I use VBE in real mode to detect and switch to high resolution video modes before switching to protected mode at boot. The function scans through supported modes and prioritizes the modes by bpp first, then pixel width, then pixel height to determine the "best" mode available

However, it is my understanding that the VBE may return modes that are not supported by the connected display. Right now I just have a hardcoded "maximum width" so only modes with pixel width equal to or below that value will be considered.

I was hoping to find a method to detect supported video modes, or at least pull some capability data, of the monitor that is connected, but I can't seem to find any information on how I may go about that.

Thanks for any assistance!

[bellezzasolo]

The official method is to support EDID. However, setting bad modes won't damage LCD monitors. You can use the Windows approach: set a mode, wait 15 seconds for the user to tell you that it works. Obviously, this isn't as easy with bootloaders. You can decide on modes that should be supported by all monitors, 720*480 or 640*480 VESA Video Modes. Or you can load the desired resolution from a configuration file, which could be as simple as an INI (there are 3rd party libraries that are fairly easy to port).

[Octocontrabass]

I don't have all the details, but you can use VBE/SCI or VBE/DDC to read the display's capabilities ROM. With SCI, you can read both EDID and DisplayID, whereas DDC only supports EDID. Personally, I'd implement both, using DDC as a fallback in case SCI doesn't work.

Finding actual copies of those standards can be tough without the full names:

VESA BIOS Extension/Serial Control Interface Standard
VESA BIOS Extensions/Display Data Channel Standard

You'll also need to refer to the DisplayID and EDID standards, which should be easier to find.

When you're choosing which mode to use, you should also pay attention to the mode timings, not just the width, height, and BPP. If you pick a mode based only on width/height/BPP, you may end up with timings that aren't supported by the display.

[kanageddaamen]

Thanks both! This is exactly what I am looking for.

In the end I will likely implement a combination of Config\Set and Test methods, but I do want to make the solution as robust as possible so I would like to cull out as many incompatible modes as I can from the selectable options. EDID looks like it is just what I am looking for

[FusT]

Thought I add a bit on this as I see too many people still being scared of destroying their displays:

However, setting bad modes won't damage LCD monitors.

Note that the "LCD" part in this is important.
(mostly older) CRT's _can_ be damaged by setting the wrong mode, though you won't be very likely to find/use one nowadays.
The Commodore PET's "killer poke" is an example of this.

This is why some (older) tutorials on setting display modes still warn about this.
Newer (late 90's) CRT's and even the oldest LCD's are modern enough to contain some logic that will simply show "Mode not supported" or something similar and not harm the display.

More explanation on the subject on StackExchange