Opened 11 years ago

Closed 11 years ago

#2791 closed bug (fixed)

1920 x 1200 resolution not useable with nVidia and Westinghouse monitor

Reported by: tigerdog Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Graphics Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

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?

Change History (23)

comment:1 by tigerdog, 11 years ago

Specific devices tested: nVidia 7600GS adaptor Westinghouse L2610NW monitor

comment:2 by jackburton, 11 years ago

Description: modified (diff)

comment:3 by jackburton, 11 years ago

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

comment:4 by axeld, 11 years ago

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.

comment:5 by tigerdog, 11 years ago

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.

comment:6 by tigerdog, 11 years ago

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

comment:7 by tigerdog, 11 years ago

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

comment:8 by tigerdog, 11 years ago

Component: Drivers/Graphics/nVidiaDrivers/Graphics

comment:9 by axeld, 11 years ago

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.

comment:10 by tigerdog, 11 years ago

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.)

comment:11 by axeld, 11 years ago

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).

comment:12 by tigerdog, 11 years ago

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.

comment:13 by tigerdog, 11 years ago

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!

comment:14 by tigerdog, 11 years ago

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

comment:15 by anevilyak, 11 years ago

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...

comment:16 by stippi, 11 years ago

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.

comment:17 by umccullough, 11 years ago

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?

comment:18 by tigerdog, 11 years ago

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?

comment:19 by tigerdog, 11 years ago

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.

comment:20 by tigerdog, 11 years ago

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?

comment:21 by axeld, 11 years ago

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?

comment:22 by tigerdog, 11 years ago

Sure. Thank you, Axel.

comment:23 by axeld, 11 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.