Also reported at Gentoo, see http://bugs.gentoo.org/show_bug.cgi?id=288570

I understand, that this bug concerns only old platform and it's unlikely that someone will fix it. But I have met this problem and will describe it here. If someone give me an advice, maybe I will try to fix it by myself.

My videocard: VIA VT8623 [Apollo CLE266] integrated CastleRock graphics
My monitor: Belinea 1730S1 (but I have tried with another monitor with the same result).

Full xorg log is attached below (via-Xorg.0.log).
The end of log:

(II) VESA(0): Searching for matching VESA mode(s):

(II) VESA(0): Total Memory: 1024 64KB banks (65536kB)
(EE) VESA(0): No matching modes
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules/libint10.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules/libvbe.so
(EE) Screen(s) found, but none have a usable configuration.

So, the problem is that "no matching modes" found. I can't uderstand, why.

I think, that another solution for this problem is to make an option to disable getting EDID information. Vesa driver ignores all options like "NoDDC", "NoDDCValue", etc. If we have such option, we could set the mode manually...

Created attachment 39058 [details]
full xorg log.

Aha, with xserver 1.7.7, which is like debian testing. Let me see whether i can get an install going on a CLE266/KM400 machine on friday evening.

I wouldn't be surprised if this is a bug in the VESA BIOSes of these things, i dealt with an IBM vesa bug at SUSE which turned out to be an issue with the Chrome9 VESA bios.

NoDCC should always work iirc. It could be something else entirely, especially since we are dealing with the bios.

My videocard (CLE266) was working with Xorg 1.3. Is it because old Xorg didn't rely on videocard bios? And now do?
Ang again, I tried options "NoDDC", "NoDDC1", "NODDC2", "NoDDCValue", "IgnoreEDID" with no effect. Also, I didn't found any options (cases, conditions) in vesa driver source - DDC is always used.

Urgh... They even broke the vesa driver...

Hah.

This seems like a build option thing... opensuse 11.something with xserver 1.5.2 is just happy, while everyone and everything else breaks using the hardware...

I guess this will prove to be the difference inn x86 support between the different distributions. As SUSE employs, still, one of the people who integrated x86emu with the xserver, Egbert Eich, SUSE will undoubtedly still be running x86emu instead of lrmi/libx86.

Some subtle difference in interpretation of some calls leads the other distributions to have some VESA calls return the standard "VBE failed" (0x14f) error, while SUSE just works. Since it does return the standard 0x14F error, the basic infrastructure is working, but something subtle is interpreted differently.

This will be _FUN_ to debug, I think i will start taking read-edid code apart to locate the exact opcode in the VESA bios where it does go wrong. I have this bios dissasembled to the exact failing calls already.

Ok, status report before i start hacking again:
* the debian xserver with vm86 works, with x86emu it breaks.
* read-edid was analysed and then completely rewritten... Check out http://cgit.freedesktop.org/~libv/vbe-edid be-edid dumps nicely on the aspire, when an external monitor is attached, and a hacked version handles the call that fails on x86emu nicely, as of course, it also uses vm86.
* next up: testing x86emu more directly...

Created attachment 39498 [details]
Result of vbe-edid work.

Thank you very much for your work! I compiled your utility and ran it on my CLE266 videocard (VIA C3 platform). The result file is attached.
Unfortunately, I don't know the EDID structure and can't understand is result bad or good. :)

I have a patch sitting at home, it needs testing inside the xserver, and then i'll send it upstream. More on that tomorrow morning (CET - doing nokia stuff now, and gf needs me in the evening)

Patch is on the ml: http://lists.x.org/archives/xorg-devel/2010-October/014483.html

Feel free to add it in a debian build tree's patchset, it works just fine there.

Sorry for long delay.
Unfortunately, xorg 1.7.7 with your patch still doesn't work at VIA CLE266 videocard with vesa driver.
If you are still interested, I can provide any kind of configs and logs...

Yeah, a log of Xorg -logverbose 7 would be nice for this one.

Either something went wrong, or your cle266 bios is running into a different issue than the km400 one.

Created attachment 40201 [details]
xorg.conf

Created attachment 40202 [details]
Xorg log

While I was trying to reproduce the problem, I suddenly investigated, that the problem "No matching modes" appears only if xorg-server is built with "minimal" use-flag (I use Gentoo build system). "minimal" use flag disables next features:
xvfb xnest record xfree86-utils install-libxf86config dri dri2 glx
So, now I CAN start Xorg on my CLE266. :) BUT:
for some reason Xorg starts for a very long time (about 3 minutes), and then works normally. If I press Ctrl-Alt-F1 to switch to console, system again freezes for a couple of minutes (screen is black). The same when switching from console back to X.
I dont't know how to see what is happening when screen is black (login through ssh and run top?). Anyway, this is another problem, but I don't know is it still platform-depending or not...
I will continue the investigation.
Just in case, my config and full xorg log are attached (files xorg.conf and Xorg log).

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.