OSDev.org

Hey all,

I've just about wrapped up my vbe pre-kernel code. I have got a few questions though:

Firstly, can one use the normal vga regs to determine vertical blanking while operating under a vesa mode? I would assume if the card was vga compatible one could, but there are no guarantees that these ports would function as expected in a vesa mode?

I've added support for ddc and reading the edid. The main reason is that the list of modes vesa bios returns while supported by the adapter are not necessarily supported by the screen. I know that Brendan did a lot of work aound this with GTF some time back. Not sure if he reached any conclusions?
Initially I'm think that I should use the edid information to filter out modes which exceed the max resolution of the screen. Secondly is to determine the correct refresh/timings for crtcinfo (that's what i'm not 100% sure about how to do at the moment). One would assume (hope) that the bios would set a compatible refresh when setting a mode.

I'm also curious as to what the outcomes of all this are on dual monitor setups, if the screens are not identical, ie laptop+external, or dual-head with 2 different monitors?
I know when i test on my laptop i get a different list of vbe modes/edid back for the primary depending on if it runs on the laptop screen exclusively or on the external lcd.
What would concern me here is that it's still possible to have both screens on at the same time (not extended) but duplicated, which may lead to a refresh issue on the one possibly?

Any info would be great!
John

I would assume if the card was vga compatible one could, but there are no guarantees that these ports would function as expected in a vesa mode?

On Mach64s and Geforce2 based chips, yes the VGA registers function in high-resolution modes. On V2x00, they don't. Also, the register sizes are not always wide enough to contain the entire size of the screen, especially considering that not all bits are guaranteed to be actually implemented on real hardware.
In reality, graphics cards have two separate engines, one VGA and one Native. Depending on the hardware, registers and components might or might not be reused on-chip. Where they are, you can find the Native engine's data via the communications with the VGA engine. Moreover, chipsets usually have registers to enable/disable the VGA communications, for the purpose of not interfering with a second installed video card. Depending on the implementation, the bit might not be present, or might not be toggled for a VESA mode.

Secondly is to determine the correct refresh/timings for crtcinfo (that's what i'm not 100% sure about how to do at the moment). One would assume (hope) that the bios would set a compatible refresh when setting a mode.

There's more on that in Video Signals And Timing

I'm also curious as to what the outcomes of all this are on dual monitor setups, if the screens are not identical, ie laptop+external, or dual-head with 2 different monitors?

I have seen some hardware start up with identically set up screens. In reality, you can't know with VESA alone what the card is actually outputting to/from. Considering your laptop, your EDID data collected would be off if you change between external and integrated display after the data was collected.


Short version: Abandon all hope, ye who enters here.

Hi,

johnsa wrote:I've added support for ddc and reading the edid. The main reason is that the list of modes vesa bios returns while supported by the adapter are not necessarily supported by the screen. I know that Brendan did a lot of work aound this with GTF some time back. Not sure if he reached any conclusions?

He did - he concluded that VBE isn't very good (even though it's still the best option).

Here's my "extreme VBE guide".

First, you can't determine if a video mode will definitely work or not - you can only really calculate/estimate the probability that a video mode might work. Also, the CRTCINFO stuff is only supported on some (not all) video cards that support VBE3 (and you'll probably find bugs in some cards that do support CRTCINFO).

For setting up a video mode, here's my recommended method:

• Try to get EDID from the monitor. I haven't found a monitor that returns dodgy information (yet) but I haven't tested many, and I wouldn't assume that no monitor ever returns dodgy information. I'd use the vendor and product in the EDID returned by the monitor to search for "corrected EDID information" for the monitor in some sort of database or file system (in my case, in the boot image). This allows you to override the monitor's EDID automatically if it's known to be dodgy, and even supply newer EDID data (with more information) for older monitors.
• In some cases you'll fail to get EDID from the monitor. All of the monitors I use do support EDID (but some of the old video cards don't); and because I'm using KVMs sometimes the video card is unable to get the EDID from the monitor when it should be able to (e.g. if a different computer is selected on the KVM and the computer being booted isn't selected). To get around that, let the user specify which "corrected EDID" data to use - if you fail to get EDID from the monitor, and if the user hasn't specified an alternative, then assume the monitor is "VGA only".
• Regardless of where EDID came from, use it to work out the maximum and minimum horizontal and vertical frequencies the monitor supports, and the maximum and minimum "dot clock" frequency (although this shouldn't matter for CRT monitors). The EDID data may have this information (e.g. newer versions of EDID), but if it doesn't (e.g. older versions of EDID) you can work it out from the video modes the monitor says it supports. Of course if there's no EDID then you'd use default VGA values.
• Next, get a list of video modes from VBE. I'll call these the "base modes". For the "base modes" you've got no idea which timing the video card would use (and therefore you can't know if the monitor will/won't support the "base mode"). The only thing you can do is use CRTCINFO to force the timing. If the video card does support CRTCINFO, then use the "base mode" to generate "fixed modes" that comply with standard VESA video modes. For example, for a "800 * 600 with 16 bits per pixel and unknown refresh rate" video mode, you might be able to use CRTCINFO to create 60 Hz, 75 Hz and 80 Hz versions. Also, CRTCINFO can be used (on some "base modes" on some video cards) to create "double scanned modes". Put the "base mode" and all of the variations (different refresh rates, with/without double scan) into your own list of video modes. Also, VBE probably won't mention standard VGA modes - you can add them too.
• For each video mode in your list you need to calculate a "reliability rating" - an estimate of the chance that the video mode will/won't work, that ranges from 0% (definately won't work) to 100% (guaranteed to work). The first step is the easiest - determine if your OS can use the video mode or not and set the video mode's reliability rating to zero if the OS can't use it for any reason. Reasons could include modes with strange/unsupported pixel formats (check the "colours mask and shift" values - BGR isn't RGB), 16-colour and 256-colour modes that aren't "VGA compatible", modes that you'd need to use bank switching for, etc. You could even check if the computer has enough RAM for double buffers if you want. If a mode isn't supported by your OS then you can skip the next step for that mode (you've already determined that the reliability rating for that mode is zero).
• This is the messy part - determining the reliability rating for video modes that your OS does support. Some of the modes will have known timing (those you created with CRTCINFO, and the standard VGA modes), which makes it easier (you just check the EDID to see if the mode is supported or not and give it a high reliability rating or a very low reliability rating). Otherwise (for "base modes") you can estimate. For example, for "800 * 600 with unknown timing" you can check how many different 800 * 600 modes the monitor does/doesn't support and use that as a basis for your rating (if there's 5 standard timings for 800 * 600 and your monitor only supports 3 of them, then the reliability rating is "3/5 = 60%"); and/or you can check if the lowest possible refresh rate would result in frequencies that are below the monitor's minimum horizontal/vertical/dot clock frequencies, or if the highest possible refresh rate would result in frequencies that are higher than the monitor's minimum horizontal/vertical/dot clock frequencies and use that as the basis for the mode's reliability rating. You can also apply adjustments to the reliability rating - for example, if the monitor supports GTF or CVT then there's a higher chance it'll support "unknown" modes and you might increase the reliability rating (or decrease it if the monitor doesn't support GTF/CVT).
• While calculating/estimating reliability ratings, please note that video modes with vertical resolutions less than 400 are double scanned modes (even if VBE doesn't say so, even if VBE says it doesn't support "double scanned", and even if it's a VGA mode). In the same way, if the horizontal resolution is less than about 512 then the video card sends the each pixel twice. For example, when calculating timings (to determine how likely it is that the monitor supports the video mode), a 320 * 240 video mode should be treated as a 640*480 video mode. If you overlook this then you'll probably end up giving low resolution video modes very low reliability ratings (because the horizontal/vertical/dot clock frequencies look lower than the monitor's minimum frequencies, and/or the video mode isn't close to anything listed by the monitor's EDID).
• At this point you could remove any video modes in your list where the reliability rating is below some sort of threshold. I leave them in the list (mostly so I can see what my code did/didn't like and check the ratings; which helps when you're tweaking all the calculations/estimates, etc).
• Now you should have a list of video modes with a reliability rating that estimates how likely it is that the video mode will work on the OS, the video card and monitor. You want to calculate a score for each video mode that takes into account the user's preferences, the monitor's preferences, and the video mode's reliability rating. For example, the user might want 1024 * 768 with 70 Hz refresh rate and 15 bits per pixel, and for the monitor's EDID there's an order of preference (which is especially important for LCD monitors - the mode given the highest preference in EDID is the monitor's native resolution). I'd recommend that you start by working out how close the mode's horizontal resolution, vertical resolution, refresh rate (if known) and colour depth is to the user's preferences, then give the mode bonus points if it's one of the monitor's preferred modes. You could also have bonus points for other things (for example, use the monitor's aspect ratio to work out of how square each pixel is and give a small bonus if pixels would be square or almost square). Finally, multiply the result by the reliability rating to get the final score (where higher is better).
• Search your list of modes for the video mode with the best/highest score. When you try to set the video mode, if you fail (for any reason) then set that video mode's reliability rating and it's score to zero (or remove it from your list). If it failed because the video card doesn't support CRTCINFO properly then you might want to change the reliability rating (and score) for all video modes that use CRTCINFO (not just the one that failed). Repeat this step until you successfully set a video mode.

johnsa wrote:I'm also curious as to what the outcomes of all this are on dual monitor setups, if the screens are not identical, ie laptop+external, or dual-head with 2 different monitors?

Mostly, for dual-monitor you're out of luck. VESA tried to support dual-head video cards but (as far as I know) video card manufacturers didn't bother (and for dual video cards it can't work because only one video card's ROM can be at 0x000C0000). Basically if you're using VBE then you treat it like "single-head with single-monitor" (even if it's not). In the same way, for 3D monitors (layered LCD, stereoscopic and shutter-glasses) you're equally out of luck (even though VESA attempted to support stereoscopic and shutter-glasses).


Cheers,

Brendan

Ok, so just as I thought I was getting somewhere... i discovered I wasn't..

Here is my current predicament:
I'm using a dell d630 laptop and an external LCD screen/22" acer or 24" samsung.

So my plan was, get list of vbe modes, remove all non 24/32 bit ones, remove all without lfb/direct-color, remove any that the vbe modeinfo not supported on current h/w config is set. This would leave me with a "base" list of vbe modes, then use EDID to remove any more modes that exceed the monitors maximum resolution, then I'd just be left with the timing crtinfo issue to ensure that one of those remaining modes could be set (based on brendan's scoring suggestion possibly).

So when my laptop is closed with external monitor plugged in:
All display moves to external screen, EDID (1.3) is returned and is correct and reports a max resolution of 1680x1050.
I determine this max by using the std. timing bytes and the 8 2 byte timing entries after that.
Sofar so good except that VBE never offers 1680x1050 as a mode in the first place, so the best I could've hoped to set timing aside is 1280x1024.

When the laptop is open and the external monitor is connected but not active:
I still get the EDID block from the external screen reporting 1680x1050 which is now wrong for the laptops display which has a true max of 1280x800.
Once again 1280x800 is not a mode ever even listed by VBE. The initial VBE mode list however does change by no longer listing 1280x1024 as an option.
The highest is now 1024x768.

When the laptop is open and I physically remove the external monitor plug:
I get a different EDID at last / same list of VBE modes ... now the problem is this EDID reports a maximum resolution of 256x160 .. ????

I'm now thinking to check for the DDD extension block as well.. but I'm not sure if this is a waste of time.Either the edid is wrong, but i do have the latest bios updates on this laptop from this year so one would think the built-in adapater/edid would be right'ish. It would have a native pixel format info with aspect ratio which might override what is in the std. edid block. I'm also not sure if specifying a different controller number when reading the edid via ddc might be helpful in some way. Another option maybe to go staight to i2c bus spec and try there for something more reliable?

Just ran an app called moninfo from entech. It's raw data matches my edid, but it seems to be able to detect a preferred timing/resolution and shows it as 1280x800. I'm not sure if it's getting this from an extension block or from the base edid 1.3 block...

Hi,

johnsa wrote:So when my laptop is closed with external monitor plugged in:
All display moves to external screen, EDID (1.3) is returned and is correct and reports a max resolution of 1680x1050.
I determine this max by using the std. timing bytes and the 8 2 byte timing entries after that.
Sofar so good except that VBE never offers 1680x1050 as a mode in the first place, so the best I could've hoped to set timing aside is 1280x1024.

When the laptop is open and the external monitor is connected but not active:
I still get the EDID block from the external screen reporting 1680x1050 which is now wrong for the laptops display which has a true max of 1280x800.
Once again 1280x800 is not a mode ever even listed by VBE. The initial VBE mode list however does change by no longer listing 1280x1024 as an option.
The highest is now 1024x768.

When the laptop is open and I physically remove the external monitor plug:
I get a different EDID at last / same list of VBE modes ...

If the video card is operating as a "dual-head" video card, then the external monitor and the built-in screen would be entirely separate monitors; and you should get no information from the second display (and VBE would have no control over the second display); where "second display" could be the built-in screen or the external monitor.

If the video card is operating as a "single-head" video card, then the built-in screen may be being used as a clone/slave of the primary/external monitor (rather than being used as a separate monitor). In this case the external monitor would override the built-in screen, and (I assume) if you set a video mode that the external monitor supports but the built-in screen doesn't then the built-in screen would be disabled. It shouldn't matter if the external monitor is turned on (yet) or not.

johnsa wrote:Just ran an app called moninfo from entech. It's raw data matches my edid, but it seems to be able to detect a preferred timing/resolution and shows it as 1280x800. I'm not sure if it's getting this from an extension block or from the base edid 1.3 block...

From the EDID spec:

VESA wrote:5. Timing Information Priority Order
The BASE EDID data structure may contain four different types of discrete timing mode information, Established, Standard, Preferred and Detailed. There may also be information required to support GTF and/or CVT compliant displays. The display EDID data shall be defined with the understanding that the host shall evaluate and support the timing modes in the following order:

Code: Select all

Table 5.1 – E-EDID Timing Mode Priority

PRIORITY  Locations of All Timing Modes listed in BASE EDID and EXTENSIONS
  1         The ‘Preferred Timing Mode’ as defined in BASE EDID. See Note 2.
  2         Other ‘Detailed Timing Modes’ in the order listed in BASE EDID. See Note 3.
  3         Any additional ‘Detailed Timing Modes’ (priority is in the order listed) in optional EXTENSION Blocks to the BASE EDID --- See Note 4.
  4         Any optional 3 Byte CVT Codes (defined in optional Display Descriptors) listed in BASE EDID or an optional Extension Block. See Note 5.
  5         ‘Standard Timings’ listed in BASE EDID and in optional EXTENSION Blocks. See Note 6.
  6         Additional Timing Mode Information: Established Timings I, II & III, Default GTF, GTF Secondary Curve & CVT. See Note 7.
  7         BASE VIDEO MODE (Default VGA). See Note 8.


NOTES:
1) The expression “Priority is in the order listed” means that the timing mode nearest to the lowest address of the EDID structure (BASE or EXTENSION) in which the timing is contained has the highest priority, the timing at the second lowest address has the second highest priority, etc.
2) The first 18 Byte Descriptor Block (addresses 36h → 47h) shall contain the “Preferred Timing Mode (PTM)” - the PTM has the highest priority. For more information, refer to Section 3.10.
3) Other ‘Detailed Timing Modes’ refers to the Detailed Timings stored in the Second (addresses 48h → 59h), Third (addresses 5Ah → 6Bh) and Fourth (addresses 6Ch → 7Dh) 18 Byte Descriptors in BASE EDID. 18 Byte Descriptors may contain Display Descriptors. Some of these Display Descriptors may contain video timing information such as:
3.1) Display Range Limits (Tag #FDh) with default GTF support, GTF Secondary Curve support or CVT support. For more information, refer to Section 3.10.3
3.2) Standard Timings 9 → 14 (Tag #FAh). For more information, refer to Section 3.10.3.6
3.3) 3 Byte CVT Codes (Tag #F8h). For more information, refer to Section 3.10.3.8

Detailed Timings have a higher priority compared to the timing definitions listed above (3.1 → 3.3) and the Detailed Timings are listed (in BASE EDID) in the order of importance. Timing priorities for the timing definitions listed above (3.1 → 3.3) are defined in one or more of the following notes.

4) Any additional ‘Detailed Timing Modes’ (listed in 18 Byte Descriptor Blocks) defined in optional EXTENSION Blocks are next in the priority order list. The priority order is in the order listed. Optional EXTENSION Blocks may include: VTB-EXT, CEA861, etc. If the standard that defines the contents of the EXTENSION Block includes a priority order definition that is in conflict, then the EXTENSION Block Standard takes precedence.
5) The next timing mode definition in the priority order list is the optional 3 Byte CVT Codes. The 3 Byte CVT Codes shall be used to define video timing modes that include horizontal and vertical pixel formats that are not defined in the VESA DMT. The 3 Byte CVT Codes may be defined in Display Descriptors which can be stored in BASE EDID or optional EXTENSION Blocks (for example: VTB-EXT, etc.). The priority order of the 3 Byte CVT Codes is in the order listed (first the BASE EDID followed by the EXTENSION Block). If the standard that defines the contents of the EXTENSION Block includes a priority order definition that is in conflict, then the EXTENSION Block Standard takes precedence.
6) Standard Timings (using 2 byte codes) are next in the priority order list. Up to 8 Standard Timings may be listed at addresses 26h → 35h in the BASE EDID (Block 0) --- for more information, refer to section 3.9. If more than 8 Standard Timings are required, then up to six (9 → 14) additional Standard Timings may be listed in the Standard Timing Display Descriptor (Tag #FAh). The Standard Timing Display Descriptor may be located in the BASE EDID or in an optional EXTENSION Block (for example: VTB-EXT). For more information, refer to Section 3.10.3.6. If more than 14 Standard Timings are required, then multiple Standard Timing Display Descriptors may be used. If the standard that defines the contents of the EXTENSION Block includes a priority order definition that is in conflict, then the EXTENSION Block Standard takes precedence.
7) Additional Timing Mode Information includes Established Timings I & II & III, Default GTF, GTF Secondary Curve and CVT.
7.1) Established Timings are bit set data fields that indicate the display’s support for various DMTs defined in VESA DMT Version 1.0, Revision 10; October 29, 2004. Established Timings cannot define a priority order. Established Timings I & II are listed in BASE EDID at addresses 23h & 24h. For more information, refer to Section 3.8. Established Timings III is defined in an optional Display Descriptor (Tag #F7h). This optional Display Descriptor may be defined in BASE EDID or in an EXTENSION Block. A source may use Established Timings I, II & III to define a list of video timing modes that are supported by the display. The source cannot determine a priority order for these video timing modes.
7.2) VESA does not recommend using the Generalized Timing Formula (GTF- using default parameters or secondary curve) for new designs. VESA recommends using CVT. Refer to Section 3.10.3.3.
8) The BASE Video Mode for Windows based Personal Computers is 640x480 @ 60 Hz (VGA). Note that some computer manufacturers (not Windows-based) have elected to define the BASE Video Mode to be some other video timing mode (not VGA).

Cheers,

Brendan

Monitor
Model name............... SyncMaster
Manufacturer............. Samsung
Plug and Play ID......... SAM04D3
Serial number............ HMBS203916
Manufacture date......... 2009, ISO week 9
-------------------------
EDID revision............ 1.3
Input signal type........ Analog 0.700,0.300 (1.0V p-p)
Sync input support....... Separate, Composite, Sync-on-green
Display type............. RGB color
Screen size.............. 530 x 300 mm (24.0 in)
Power management......... Active off/sleep
Extension blocs.......... None
-------------------------
DDC/CI................... Not supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.649 - Ry 0.338
Green chromaticity....... Gx 0.289 - Gy 0.609
Blue chromaticity........ Bx 0.146 - By 0.070
White point (default).... Wx 0.313 - Wy 0.329
Additional descriptors... None

Timing characteristics
Horizontal scan range.... 30-81kHz
Vertical scan range...... 56-60Hz
Video bandwidth.......... 170MHz
CVT standard............. Not supported
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1920x1080p at 60Hz (16:9)
Modeline............... "1920x1080" 138.500 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync

Standard timings supported
640 x 480p at 60Hz - IBM VGA
800 x 600p at 56Hz - VESA
800 x 600p at 60Hz - VESA
1024 x 768p at 60Hz - VESA
1280 x 800p at 60Hz - VESA STD
1280 x 960p at 60Hz - VESA STD
1280 x 1024p at 60Hz - VESA STD
1440 x 900p at 60Hz - VESA STD
1600 x 1200p at 60Hz - VESA STD
1680 x 1050p at 60Hz - VESA STD

Report information
Date generated........... 2010/03/01
Software revision........ 2.44.0.825
Operating system......... 6.1.7600.2

Raw data
00,FF,FF,FF,FF,FF,FF,00,4C,2D,D3,04,34,32,49,4B,09,13,01,03,0E,35,1E,78,2A,60,41,A6,56,4A,9C,25,
12,50,54,23,08,00,81,00,81,40,81,80,95,00,A9,40,B3,00,01,01,01,01,1A,36,80,A0,70,38,1F,40,30,20,
35,00,13,2A,21,00,00,1A,00,00,00,FD,00,38,3C,1E,51,11,00,0A,20,20,20,20,20,20,00,00,00,FC,00,53,
79,6E,63,4D,61,73,74,65,72,0A,20,20,00,00,00,FF,00,48,4D,42,53,32,30,33,39,31,36,0A,20,20,00,72

Here is the dump from Monitor Info (the application I d/l'ed from EnTech) .. it's free and quite helpful.

I'm going to try actually set a mode now and see if the external monitor switches rather than the laptop screen based on your suggestion. Although the text is currently being displayed on the laptop and external monitor says "no signal".
That would explain it using the external's edid in preference.

Brendan, thanks a million for that info! After doing some more digging and using the above I realized the error of my way (I don't have the full edid spec, only the wikipedia article as it's no longer free from vesa):

On my acer 22" the EDID has 01 01 for every one of the 8 standard timing entries as well as 00 for established timings. So essentially with that setup I should ignore those values completely. I also noted byte 24 to contain the preferred timing bit.
So i've added to my logic:
Check byte 24 for preferred timing, if so use the values in bytes 54-61descriptor block 1 (if pixel clock is not null) as the best option.. I assume to take horizontal active and vertical active to be the actual resolution here?
Then loop through the detailed timing blocks and do the same..
Loop through the std. timings listed, ignore any that are 00 or 01 (this was the cause of my 256x160 resolution problem).
Add the established timings.
from this prioritized list determine the maximum resolution of the screen (I would assume that for an LCD/FP the native resolution should be the max .. as it can't reproduce anything higher than it's native format).
Although from the above EDID information you can see a std. timing mode of 1600x1200 supported (and 1200 is higher than the screens native resolution of 1080p, so in theory this mode shouldn't be possible?)
Perhaps if the preferred timing flag is set I should just take that PTM as the maximum and ignore the other timings?

Brendan wrote: In some cases you'll fail to get EDID from the monitor. All of the monitors I use do support EDID (but some of the old video cards don't); and because I'm using KVMs sometimes the video card is unable to get the EDID from the monitor when it should be able to (e.g. if a different computer is selected on the KVM and the computer being booted isn't selected). To get around that, let the user specify which "corrected EDID" data to use - if you fail to get EDID from the monitor, and if the user hasn't specified an alternative, then assume the monitor is "VGA only".

Be very careful here. If the user provides an EDID file with specifications greater than their monitor's actual, and they're using a laptop, then they can quite easily boil (and destroy) their LCD. Laptop LCDs tend not to have the protection external monitors do.

The Intel X.Org drivers no longer allow the user to provide their own EDID data for this reason.

Incidentally, my TV doesn't report it's actual capabilities by EDID (Though I think it's actually that it doesn't have an EDID chip and XOrg is going with "likely to work")

Brendan wrote:In the same way, if the horizontal resolution is less than about 512 then the video card sends the each pixel twice.

Iirc, I created a 160x200 video mode once, so that must've used four equal pixels being sent. But such a mode wouldn't be listed by VBE, of course...


JAL

Well sofar so good, the edid and extensions blocks are reporting everything I could want and have been correct now on about 9 different setups. So on each i've been able to tell if it's analog/digital... lcd, supported resolutions/timings in order of preference and the both the maximum / native resolution of the display. This filtering is now working well with my existing base-mode-list.

I have 2 questions, the one I mentioned before but I'm not sure if there is a work-around -> detecting vertical refresh without being able to call the BIOS or pmode interface (I'd be in long-mode). I'd assume that not all cards would still use the old vga method correctly.

Second question is around setting the vesa mode. From Brendan's suggestions sofar modes are setting correctly for me everywhere based on the filtered mode-list. I haven't been able to test the thought that a mode that was too-high might automatically switch monitors based on the edid coming through from the external rather than laptop as the vbe mode list automatically removes this option up-front.
Is it possible to set a resolution that is not in the reported mode list? or is it only possible to adjust the timing/refresh of one of these existing modes? I see that all the other functions require you to pass in the vbe mode number, like get pixel clock etc..

Hi,

johnsa wrote:I have 2 questions, the one I mentioned before but I'm not sure if there is a work-around -> detecting vertical refresh without being able to call the BIOS or pmode interface (I'd be in long-mode). I'd assume that not all cards would still use the old vga method correctly.

The old "VGA refresh in progress" bit might work if the Capabilities field in VBE's "Controller Info" says the card is VGA compatible and the ModeAttributes field in VBE's "Mode Information" says the video mode is VGA compatible, but it'd take a lot of testing to verify this is actually the case on all available video cards (rather than just my wishful thinking); and it really wouldn't help much (because higher resolution video modes won't be VGA compatible anyway).

The only other alternative is to bypass VBE (write a native video driver for the video card); which would probably give you a usable refresh bit and a usable vertical retrace IRQ.

johnsa wrote:Is it possible to set a resolution that is not in the reported mode list? or is it only possible to adjust the timing/refresh of one of these existing modes? I see that all the other functions require you to pass in the vbe mode number, like get pixel clock etc..

Using VBE you can't change the horizontal resolution, vertical resolution or colour depth of a video mode (only the timing). Unfortunately, the VBE in most video cards only offer "standard 4:3" video modes (e.g. 640*480, 800*600, 1024*768, 1280*1024, 1600*1200), which means that people with wide screen monitors don't get square pixels and people with wide screen LCD can't have the monitor's preferred resolution.

The only way around that is to bypass VBE (write a native video driver for the video card). In that case you could probably configure (almost) any horizontal resolution and vertical resolution you like.

Mostly what I'm saying here is "VBE isn't very good" (but still better than nothing)...


Cheers,

Brendan

Thanks That's pretty much what I thought.
For now though it's perfectly adequate I guess. I have much more work todo before this becomes a major issue, and once it does I have the ati and intel documentation.. and some sample code. Plus the ATI ppl I know are quite helpful so I'm sure I'll be able to begin working on a native driver for the few specific cards I'd want to support and even then I'm not interested in 3d just straight 2d, frame-buffer and maybe some blit acceleration. Until then...

Thanks for all the help!