Comment 84 for bug 3731

I doubt the 64-bitness is a problem here, because it got the EDID data from my monitor. The vesa driver has to use an x86 emulator to run code from the video BIOS, but I think it manages that fine (Fine here, but not on my Tecra 8000).

I looked at the source code for ddcprobe (part of xresprobe) and found the part where it calculates "ctimings":

 /* Standard timings. */
 for(i = 0; i < 8; i++) {
  double aspect = 1;
  unsigned int x, y;
  unsigned char xres, vfreq;
  xres = edid_info->standard_timing[i].xresolution;
  vfreq = edid_info->standard_timing[i].vfreq;
  if((xres != vfreq) ||
     ((xres != 0) && (xres != 1)) ||
     ((vfreq != 0) && (vfreq != 1))) {
   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 that's how it detected "1680x1680" and "1440x1440": It thinks there's an aspect ratio of 1 because of an "undefined" condition. Is this the same code that Ubuntu uses to configure xorg.conf for the vesa driver? If so, that would explain everything.

By the way, has anyone ever looked at edid-decode? It's awesome. It's in the xorg git tree here: http://gitweb.freedesktop.org/?p=xorg/app/edid-decode.git;a=summary
I tried it on my EDID and it correctly parsed EVERYTHING. The output is attached.

So, I know how people can help with this issue:
Make ddcprobe more like edid-decode. :)