1920 x 1200 resolution not useable with nVidia and Westinghouse monitor

[tigerdog]

One of the changes to 1920 x 1200 resolution, either hrev19753 or hrev22955, causes this resolution to be unusable here. Currently running fine under BeOS and Zeta using older version of driver (built 12 April 2006.) Also works fine under Ubuntu with

modeline "1920x1200@60" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -hsync +vsync

Can we possibly present two versions of this resolution in the menu?

[tigerdog]

Specific devices tested: nVidia 7600GS adaptor Westinghouse L2610NW monitor

[jackburton]

I think we could just use revert hrev22955, since it turned out to be problematic, at least on some configurations.

[axeld]

The best would be to implement EDID support in the nVidia driver, then the mode specified by the monitor could be used.

hrev22955 fixed a specific problem for Hartmut Reh, but I'm not sure if the previous mode was completely unusable. Until that's cleared, I would be for reverting that change, too.

[tigerdog]

I don't have the ability to build Haiku here ATM. It might be worth building a test version with the old modeline and letting me test before reverting the code, to make sure the issues I'm seeing are attributable to the changed modeline.

[tigerdog]

just curious - has hrev22955 been reverted yet? I'm still seeing the same issues with the "pre-alpha" build Axel put on haiku-files.

[tigerdog]

BTW, further testing confirmed I'm seeing this problem with the VESA driver. I'm currently having problems with the nVidia driver here.

[axeld]

This is not correct: the VESA driver doesn't use any modelines, so changing them in the driver won't have any effect. If you have the problem in VESA, too, it seems that your monitor is picky, and doesn't support the default VESA modeline that your nVidia graphics card is using for that resolution.

There is nothing we can do about the VESA driver.

[tigerdog]

Thanks, Axel. The modeline request still stands, though, in hopes that Rudolph is able to fix the issue preventing me from using the nVidia accelerated driver (ticket #2948.)

[axeld]

Can you provide a syslog with EDID output of that monitor? Apparently, DVI has a certain bandwidth restriction (165 MHz) that should prevent it from showing the mode with a single link with 193.16 MHz as above.

If the monitor shows the right EDID line, it shouldn't be a problem, though, as we could then just use that one (the nVidia driver still does not support EDID yet, though).

[tigerdog]

I'll take a look at the syslog and attach what I find to the bug. There may be another complicating factor, in that I use the analog VGA connection and not DVI. I have to because I run through a KVM switch; that may also be introducing complications.

[tigerdog]

Here is the output from the top of the syslog file. I hope this helps:

KERN: APM version 1.2 available, flags 7. KERN: smp: using ACPI to detect MP configuration KERN: smp: local apic address is 0xfee00000 KERN: smp: found local APIC with id 0 KERN: smp: found local APIC with id 1 KERN: smp: found io APIC with id 2 and address 0xfec00000 KERN: VESA version = 3.0 KERN: OEM string: NVIDIA KERN: 100: 640 x 400 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 101: 640 x 480 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 102: 800 x 600 x 4 (a = 799, mem = 3, phy = 0, p = 4, b = 1) KERN: 103: 800 x 600 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 104: 1024 x 768 x 4 (a = 799, mem = 3, phy = 0, p = 4, b = 1) KERN: 105: 1024 x 768 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 106: 1280 x 1024 x 4 (a = 799, mem = 3, phy = 0, p = 4, b = 1) KERN: 107: 1280 x 1024 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 10e: 320 x 200 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 10f: 320 x 200 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 111: 640 x 480 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 112: 640 x 480 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 114: 800 x 600 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 115: 800 x 600 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 117: 1024 x 768 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 118: 1024 x 768 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 11a: 1280 x 1024 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 11b: 1280 x 1024 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 130: 320 x 200 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 131: 320 x 400 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 132: 320 x 400 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 133: 320 x 400 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 134: 320 x 240 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 135: 320 x 240 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 136: 320 x 240 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 13d: 640 x 400 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 13e: 640 x 400 x 32 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 145: 1600 x 1200 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 146: 1600 x 1200 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 147: 1400 x 1050 x 8 (a = 927, mem = 4, phy = d0000000, p = 1, b = 1) KERN: 148: 1400 x 1050 x 16 (a = 927, mem = 6, phy = d0000000, p = 1, b = 1) KERN: 152: 2048 x 1536 x 32 (a = 987, mem = 6, phy = d0000000, p = 1, b = 1) KERN: VESA compatible graphics! KERN: EDID1: 4f KERN: EDID2: ebx 0 KERN: Welcome to the Haiku boot loader!

[tigerdog]

oops - that's pretty much unreadable. I tried two times to upload a file but received an error from Trak. Suggestions?

[anevilyak]

For multiline output like that, Trac has operators for printing it unchanged. Enclose the whole block of text with { { { and } } } (without the spaces between brackets) and it will leave the formatting alone. File upload is another issue...

[stippi]

You are driving a monitor at 1920x1200 via VGA?! The analog output of most graphics cards really sucks at such high resolutions. I would recommend getting a DVI KVM switch instead. Depending on the KVM, it may also screw up proper EDID retrieval.

[umccullough]

FWIW, I drive 1920x1200 as well, through a KVM (and it's not bad actually, no perceptable ghosting here)

Interesting that you note it might return different EDID info through the KVM...

Is there a tool we can run from terminal to request EDID info easily? I think I should run a few tests here myself and start keeping track of what my various cards/monitors/configurations report. Can the EDID info also be polled after connected a different screen on-the-fly?

[tigerdog]

Yak, thanks for the pointer. I'll use it next time. stippi, the card output is actually very good but I had to invest in a very high-qualit VGA cable to make the run across the room. I haven't yet found a (cheap) DVI KVM and the laptop that shares the connection is VGA only, so I think I'm just going to have to be the test case here.

Seems like EDID info is very limited compared to the info from the kernel query of the graphics card. Is the mode info above what's reported by the card?

[tigerdog]

New Info: I am now able to use nvidia accelerated graphics here, so I have tested different modelines in ProposeDisplayMode.c. The problems I see are definitely caused by the 1920x1200 modeline introduced by revision 22955. I am able to get a satisfactory display using the older modeline. However, I also tested using a modeline modeled on windows and Linux.

/* 16:10 panel mode; 2.304M pixels */
{ { 193160, 1920, 2048, 2256, 2592, 1200, 1201, 1204, 1242, T_POSITIVE_SYNC}, B_CMAP8, 1920, 1200, 0, 0, MODE_FLAGS}, /* Vesa_Monitor_@60Hz_(1920X1200) */

This produces a more stable display, at least with my monitor and card.

[tigerdog]

If anyone knows how to contact Dr. Hartmut Reh, I'd be happy to work together with him to find a compromise to work with as many monitors as possible. In the meantime, will you be able to revert 22955 in svn?

[axeld]

The graphics driver is responsible for retrieving the EDID data. In any case, the boot loader does dump its EDID info to the serial debug output, and if the buffer is large enough, it will also end up in the syslog.

Modeline applied in hrev28913. Can I close the ticket for now?

[tigerdog]

Sure. Thank you, Axel.