feisty fresh install sets xorg.conf to 1440x1440 instead of 1440x900 nvidia

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please add your '/etc/X11/xorg.conf' file and your '/var/log/Xorg.0.log' file as attachments to your bug report? Thanks in advance.

my xorg.conf

(i have added the nvidia binary driver - but obviously the bug was with the original fresh install with the "nv" driver)

/var/log/Xorg.0.log

>> my xorg.conf
>> (i have added the nvidia binary driver - but obviously the bug was with the original fresh install with the "nv" driver)

I have experienced the same problem on a few machines with Nvidia cards - including the one I have just done a fresh install on and am using now I will attach the original files. Probably a bit late but if it helps it helps and if not nothing is lost.

Can you please attach the output from the following? xresprobe <driver>, ddcprobe, xrandr.
Also, run dexconf -o /tmp/dexconf-xorg.conf and attach that file.

This is an odd bug, but I think I've seen it mentioned by others. There must be a logic bug resulting in 1440x1440 rather than 1440x900.

I've also seen reports of a 1680x1680 variant.

Another thing to get details from is get-edid:

 sudo apt-get insteall read-edid
 get-edid | parse-edid

I'm interested in if this gives the same results; if so, then the error is likely to be something with the hardware. If not, then it's a bug in ddcprobe.

Thanks, if we can get this data soonish, we may be able to have a fix for this in by Gutsy.

Results with nvidia card in the box.

$ xresprobe nv
id: SyncMaster
res: 1440x1440 1280x1024 1280x960 1152x864 1024x768 832x624 800x600 720x400 640x480
freq: 30-81 56-75
disptype: crt

$ ddcprobe
vbe: VESA 3.0 detected.
oem: NVidia
vendor: NVidia Corporation
product: NV18 () Board Chip Rev A2
memory: 65536kb
mode: 640x400x256
mode: 640x480x256
mode: 800x600x16
mode: 800x600x256
mode: 1024x768x16
mode: 1024x768x256
mode: 1280x1024x16
mode: 1280x1024x256
mode: 80x60 (text)
mode: 132x25 (text)
mode: 132x43 (text)
mode: 132x50 (text)
mode: 132x60 (text)
mode: 320x200x64k
mode: 320x200x16m
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
mode: 1024x768x64k
mode: 1024x768x16m
mode: 1280x1024x64k
mode: 1280x1024x16m
edid:
edid: 1 3
id: 0273
eisa: SAM0273
serial: 4d453139
manufacture: 8 2007
input: separate sync, composite sync, sync on green, analog signal.
screensize: 41 26
gamma: 2.350000
dpms: RGB, active off, no suspend, no standby
timing: 720x400@70 Hz (VGA 640x400, IBM)
timing: 720x400@88 Hz (XGA2)
timing: 640x480@60 Hz (VGA)
timing: 640x480@67 Hz (Mac II, Apple)
timing: 640x480@72 Hz (VESA)
timing: 640x480@75 Hz (VESA)
timing: 800x600@60 Hz (VESA)
timing: 800x600@72 Hz (VESA)
timing: 800x600@75 Hz (VESA)
timing: 832x624@75 Hz (Mac II)
timing: 1024x768@87 Hz Interlaced (8514A)
timing: 1024x768@70 Hz (VESA)
timing: 1024x768@75 Hz (VESA)
timing: 1280x1024@75 (VESA)
ctiming: 1440x1440@60
ctiming: 1440x1440@75
ctiming: 1280x1024@60
ctiming: 1280x960@60
ctiming: 1152x864@75
dtiming: 1440x900@69
monitorrange: 30-81, 56-75
monitorname: SyncMaster
monitorserial: HSAP205821

$ xrandr # after editing xorg.conf, not in gg live cd!
Screen 0: minimum 320 x 240, current 1440 x 900, maximum 1440 x 1024
default connected 1440x900+0+0 0mm x 0mm
   1440x900 50.0* 58.0 59.0
   1280x1024 51.0 60.

$ get-edid | parse-edid
get-edid: get-edid version 1.4.1

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
 Function supported
 Call successful

 VBE version 300
 VBE string at 0x11110 "NVidia"

VBE/DDC service about to be called
 Report DDC capabilities

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
 Function supported
 Call successful

 Monitor and video card combination does not support DDC1 transfers
 Monitor and video card combination supports DDC2 transfers
 0 seconds per 128 byte EDID block transfer
 Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
 Read EDID

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
 Function supported
 Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
parse-edid: parse-edid version 1.4.1
parse-edid: IO error reading EDID

Xorg.conf created by dexconf attached.

 XRESPROBE_DEBUG="DEBUG" ./xresprobe a
laptop: ; ddc: yes
attempting DDC detection
raw timings - 1440x900 1440x1440 1440x1440 1280x960 1280x1024 1280x1024 1152x864 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 720x400 720x400 640x480 640x480 640x480 640x480
id: SyncMaster
res: 1440x1440 1280x1024 1280x960 1152x864 1024x768 832x624 800x600 720x400 640x480
freq: 30-81 56-75
disptype: crt
id: SyncMaster
res: 1440x1440 1280x1024 1280x960 1152x864 1024x768 832x624 800x600 720x400 640x480
freq: 30-81 56-75
disptype: crt
not cleaning up after Xorg; not forked

Should be fixed with the newest xresprobe :
Accepted:
xresprobe 0.4.24ubuntu6 was ACCEPTED.
 Component: main Section: x11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 10 Oct 2007 18:21:05 +0300
Source: xresprobe
Binary: xresprobe
Architecture: source
Version: 0.4.24ubuntu6
Distribution: gutsy
Urgency: low
Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss at lists.ubuntu.com>
Changed-By: Timo Aaltonen <tepsipakki at ubuntu.com>
Description:
 xresprobe - X Resolution Probe
Changes:
 xresprobe (0.4.24ubuntu6) gutsy; urgency=low
 .
   [Tormod Volden]
   * lcdsize.sh: fix vesa sed regexp so that resolutions are returned
     correctly without trailing text.
Files:
 7fb2423b59d235f9f41f598aea286b22 705 x11 optional xresprobe_0.4.24ubuntu6.dsc
 16d86df9e3188ca5d70eb6d343d2019e 202629 x11 optional xresprobe_0.4.24ubuntu6.tar.gz
Original-Maintainer: Debian X Strike Force <debian-x at lists.debian.org>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDO8jCf/ckHZoKjcRAkdXAJ9EGksAnp3EKP2B+5nmVlONAhjTdgCeOJe/
phHqSiwDZy9U3v5JkhjJIek=
=T76w
-----END PGP SIGNATURE-----

Works here.

Sorry, I'm blind :)
I was looking for a Gutsy bug with the same effect.
Restoring previous status.

It sounded strange, because I've thought problem is not in some shell script, but in ddcprobe binary. Problem it, it defaults to 1,0 ratio, if it can't find correct one via EDID. OK, real problem is it can't find correct one. Maybe the best thing you can do is use Xorg autodetection and rewrite tools for setting resolution, frequency and thanks like that to deal with it.

btw. could you please give me a link to docs how to build gutsy live cd with this package changed, I would like to do some testing? thanks!

PS: sorry for this offtopic

Aha, I see that the relevant code for this is here, in ddcprobe.c:

        for(i = 0; i < 8; i++) {
                        ...
                        switch(edid_info->standard_timing[i].aspect) {
                                case 0: aspect = 1; break; /*undefined*/
                                case 1: aspect = 0.750; break;
                                case 2: aspect = 0.800; break;
                                case 3: aspect = 0.625; break;
                        }
                        x = (xres + 31) * 8;
                        y = x * aspect;
                        printf("ctiming: %dx%d@%d\n", x, y,
                               (vfreq & 0x3f) + 60);

So like pheeror says, the 1 aspect ratio is being returned in the case where EDID is failing.

I see in ddcprobe.sh, it has this code to check for a return value of 1:

...
  DDCPROBE="$(ddcprobe 2>/dev/null)"
...
if [ "$?" = "1" ]; then
  exit 1
fi

But I imagine there is some code somewhere (maybe in xserver postinst?) which is not properly checking for this?

Perhaps better logic would be to skip outputting the mode at all in this case? E.g. something like...

        for(i = 0; i < 8; i++) {
                       ...
                       switch(edid_info->standard_timing[i].aspect) {
                                case 0: continue; break; /*undefined*/
                                case 1: aspect = 0.750; break;
                                case 2: aspect = 0.800; break;
                                case 3: aspect = 0.625; break;
                        }

My bad - ddcprobe.sh is *not* checking for the _output_ code of "1" but the error code of "1". So it's not actually handling this error condition properly.

Further, looking at the EDID 1.1 spec (or, rather, Wikipedia's report about it), it clearly says that in the 0 case in the switch above, it's not undefined but rather corresponds to a 16:10 aspect ratio, so should be using aspect = 0.625 in this case. Oddly, the spec (again, according to Wikipedia) also says the 3 case should be 16:9 (0.5625).

Here is a fix for this issue. It turned out that in early versions of EDID, 'aspect=0' was used to indicate a 1:1 aspect ratio, but in later versions like 1.3 and 2.0, they redefined it to mean a 16:10 aspect ratio. I guess ddcprobe was developed prior to this change, so was just assuming 1:1 for all versions of EDID info, and thus resulted in this bug.

The attached ddcprobe contains new logic, based on the xserver EDID handling code, to account for this properly. In addition, while looking at the code I saw that the 'aspect=3' case was simply incorrect; it is using a 16:10 ratio there, whereas in the specification, and in xserver, it clearly should be 16:9. I'm curious about this mistake, and why it appears not to have caused issues for anyone, but I suppose it's just a rare corner case, and probably hidden by other xresprobe bugs. Or maybe it's been reported elsewhere, or has symptoms that aren't being recognized as an xresprobe issue. In any case, I think coupled with the above fix, this may open up additional resolutions for users of 16:9 ratio hardware.

Thanks for you effort and patches :-)

Hi, xresprobe is no longer used in Hardy Heron, the development version which will become Ubuntu 8.04. Because of that I'm closing this bug. Please test Hardy (alpha3 or later), and if your hardware still fails to get a correct resolution (or if it drops to failsafe mode), file a bug against the driver package (xserver-xorg-video-$driver). Thanks!