[regression] 7.2 broke vesa: "No matching modes found"

Reported by Andrea Colangelo on 2007-03-05
Affects Status Importance Assigned to Milestone
X.Org X server
xorg (Ubuntu)
xorg-server (Ubuntu)
xserver-xorg-video-vesa (Ubuntu)

Bug Description

Binary package hint: xorg

Downloaded Feisty Herd 5 desktop x86 image, checked hash, burned and verified a cd.
The testing machine is a laptop: Dell Inspiron 6400, an Intel Core 2 Duo with a Radeon Mobility X1400 and 1280x800 widescreen display.

Launching the Live CD, at the end of the boot process a dialog box says that gdm cannot start, and the boot ends with console login.
The error message after a startx is:
(EE) VESA(0): No matching modes
(EE) Screen(s) found, but none have a usable configuration.

The solution is editing xorg.conf and adding "HorizSync 36-52" and "VertRefresh 36-60" in "Section Monitor". Giving a startx, the desktop appears with normal resolution for the vesa driver (cannot use radeon driver on this machine).
Also, a sudo dpkg-reconfigure xserver-xorg, even accepting all default choices, solves the problem.

This appears a minor bug, but a non-geek user would have troubles debugging it. Also, Feisty Herd 3 and 4 went straight to the desktop, so this is a regression from older releases

Andrea Colangelo (warp10) wrote :
description: updated
Changed in xorg:
status: Unconfirmed → Confirmed

could you try booting it without usplash: remove 'splash' from the kernel boot commands and see if that helps.

Andrea Colangelo (warp10) wrote :

Doesen't help. It just remain the same as above.

SBrewer (sbrewer) wrote :

This is a me too. Same machine, same graphics card. Xorg does not start, so install is impossible.

The graphics card is not supported by X, so vesa is the correct driver in this case. I tried copying the xorg.conf from 6.10 and that did not help.

This is quite a popular laptop by the way, so I assume there will be others who are affected.

Timo Aaltonen (tjaalton) wrote :

Could you attach (not paste) /var/log/Xorg.0.log, /etc/X11/xorg.conf and the output of commands lspci -vv and lspci -nvv.

SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :

More information:

I tried Andrea's fix for the HorizSync and VertRefresh and it worked
for me too.

I dont think the problem is in the xorg.conf however, but probably something going wrong with the ddc probe. Just a guess.

Timo Aaltonen (tjaalton) wrote :

indeed, please post what 'sudo xresprobe vesa' and 'ddcprobe' outputs.

SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :
SBrewer (sbrewer) wrote :

Ok here is something else interesting.

Here is a Xorg.0.log from the 6.10 bootdisk (which works properly).

Some bug in X 7.2??

Timo Aaltonen (tjaalton) wrote :

please attach the xorg.conf you had with 6.10 livecd.

SBrewer (sbrewer) wrote :
Timo Aaltonen (tjaalton) wrote :

hm, the relevant bits look identical.

SBrewer (sbrewer) wrote :

This line is extra in the failing Xorg.0.log

(II) VESA(0): Modeline "1280x800" 71.11 1280 1328 1360 1440 800 802 808 823 -hsync -vsync

Dont ask me what it means though :-)

Timo Aaltonen (tjaalton) wrote :

good catch!

SBrewer (sbrewer) wrote :

ok, so what happens now? Do I drive a bugfix from upstream?
Or can you do that?

The other option is to hack up the autodetection to work around the

Changed in xorg-server:
status: Unknown → Confirmed
Changed in xorg-server:
status: Confirmed → Fix Released
SBrewer (sbrewer) wrote :

Maybe some bad news on this one. The new vesa driver (1.3) will probably not fix the problem.

The fedora guys already have 1.3 and the problem is still there. From what I can tell, the problem comes from changes in the xserver that went into 7.2.


The fedora guys fixed the problem by adding the attached hack to the vesa driver.

So the upstream bug in Xorg is not fixed; only Fedora 7 has the fix so far.

Timo Aaltonen (tjaalton) wrote :

Thanks for the patch, I've seen it before, and it'll be included in the ubuntu package soon.

Changed in xorg:
status: Confirmed → In Progress
SBrewer (sbrewer) wrote :

Great and thanks for the follow up. Please let me know when the fix makes it to a test CD and will try it out and report back.

Changed in xorg-server:
status: Fix Released → Confirmed
Timo Aaltonen (tjaalton) wrote :

that patch is now in Feisty, and you can test it with the fresh Feisty beta livecd. Although, that might not be the real fix, see bug #95253

Changed in xserver-xorg-video-vesa:
assignee: nobody → tepsipakki
Timo Aaltonen (tjaalton) wrote :

Hold on.. that upload did _not_ make it in beta, so testing that won't help. The upload got in yesterday, so please test that if possible.

SBrewer (sbrewer) wrote :

I just tested this one:

feisty-desktop-i386.iso 26-Mar-2007 07:44 697M

777783ae247bdc59e701b91792322a37 *feisty-desktop-i386.iso

Did not work unfortunately. I did not check if the latest vesa driver
made it into this image.

SBrewer (sbrewer) wrote :

Fedora has a new driver out in the last few days that attempts to address (probably) the same problem. This is now at 1.3.0-5.fc7

As an experiment I extracted vesa_drv.so from the fedora package. Then I booted into an alpha version of the Ubuntu Feisty livecd, and copied over the vesa driver. Then i tried startx and the Xorg log had the same result.

I am starting to think that the only real way to debug this is to put in detailed debugging output in the mode selection part of the driver. I looked at how much effort it would take to build vesa_drv from source, but ran out of time.

Is there a simple set of instructions for building the driver?

SBrewer (sbrewer) wrote :

I think the Fedora patch is wrong, or is fixing a different problem. The Fedora patch is never even reach in the failure case presented in this bug report.
See my analysis here:

====== Cut from Vesa.c =========
    pScrn->modePool = VBEGetModePool (pScrn, pVesa->pVbe, pVesa->vbeInfo,

    xf86ErrorFVerb(DEBUG_VERB, "\n");
    xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, DEBUG_VERB,
     "Total Memory: %d 64KB banks (%dkB)\n", vbe->TotalMemory,
     (vbe->TotalMemory * 65536) / 1024);

    pVesa->mapSize = vbe->TotalMemory * 65536;
    if (pScrn->modePool == NULL) {
 xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "No matching modes\n");

****** This is where the VESA driver bombs out ******
 return (FALSE);


****** Fedora patch starts here !!! *******
    i = VBEValidateModes(pScrn, NULL, pScrn->display->modes,
     NULL, NULL, 0, 2048, 1, 0, 2048,
     pVesa->mapSize, LOOKUP_BEST_REFRESH);

    if (i <= 0) {
 xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "No valid modes\n");
 return (FALSE);

Timo Aaltonen (tjaalton) wrote :

Could you try the latest vesa, because the patches are now applied to it correctly. In fact, they weren't applied to the old version at all..

Timo Aaltonen (tjaalton) wrote :

Oh, sorry I forgot you were testing the livecd. The current daily might have it, if the image isn't oversized.

SBrewer (sbrewer) wrote :

tried todays build (on a DVD) and still no good.

Please see this comment:

There could be two bugs here. I would suggest getting Xorg.0.log from bug 95253 and checking if the error message is 'No matching modes' or 'No valid modes'. If they have a different error message, then that bug is different to this one.

For me it is 'No matching modes' while for others on the internet it is the latter error. The fedora patch fixes the latter, but cannot fix the former, since it does not change any code that applies to it.

Timo Aaltonen (tjaalton) wrote :

Yes, you are right. Don't know why it fails now. Since Herd5 didn't have the new vesa-driver, the fault must lie in xorg-server.

Changed in xserver-xorg-video-vesa:
importance: Undecided → Medium
status: In Progress → Confirmed
Mantas Kriaučiūnas (mantas) wrote :

Maybe we should just patch xserver-xorg.postinst script to always use on Radeon Mobility X1400 cards, like there already is such lines for other cards ? for example such code could be added in xresprobeint() function of xserver-xorg.postinst script:

    if [ "$DEVICE_DRIVER" = "vesa" ]; then
      if [ "$DISPLAY_TYPE" = "lcd/lvds" ]; then
        if [ "$DEVICE_IDENTIFIER" = "ATI Technologies, Inc. Radeon Mobility X1400" ] || \
           echo "$DEVICE_IDENTIFIER" | grep -q "Radeon Mobility X1400"; then
          debug_echo "Radeon Mobility X1400 laptop chipset detected; writing sync ranges"

I can test and attach such patch if Ubuntu developers will accept my patch.

Timo Aaltonen (tjaalton) wrote :

ok, a quick test for you all:

please run "discover --disable=serial,parallel,usb,ide,scsi --format="%V %M\t%S\t%D\n" video | awk 'BEGIN { FS="\t" } {print $1}'"

and post the result. It seems that the ATI vendor string should be without a comma and a dot. There are similar entries in the postinst, and they all seem to be wrong :) The vendor string might have been changed in discover-data some time ago...

Timo Aaltonen (tjaalton) wrote :

Don't bother, it's confirmed that the vendor string was changed in discover-data.

Timo Aaltonen (tjaalton) wrote :

this seems to affect some other X1xx cards as well.. Enfortunately, the fix didn't wasn't accepted in Feisty final, but maybe as a post-release update.

Timo Aaltonen (tjaalton) wrote :

bah, silly typo.. that was "_un_fortunately"

How can that be possible? There is no way it will make it to the final release of feisty? It isn't even out yet...

-----Original Message-----
From: Timo Aaltonen <email address hidden>
Date: Tue, 17 Apr 2007 05:33:27
To:<email address hidden>
Subject: [Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"

this seems to affect some other X1xx cards as well.. Enfortunately, the
fix didn't wasn't accepted in Feisty final, but maybe as a post-release

** Changed in: xorg (Ubuntu)
Sourcepackagename: xorg-server => xorg

[regression] 7.2 broke vesa: "No matching modes found"
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Timo Aaltonen (tjaalton) on 2007-04-17
Changed in xorg:
status: Confirmed → Needs Info
importance: Medium → High
95 comments hidden view all 175 comments
mabovo (mabovo) wrote :
Download full text (48.7 KiB)

Installing fglrx driver 8.40.4 on Tribe4 got this message:

marcos@linux-ubuntu:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0)


I think some problem with kernel version ? Here is my Xorg.0.log

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Linux Ubuntu
Current Operating System: Linux linux-ubuntu 2.6.22-9-386 #1 Fri Aug 3 00:21:52 GMT 2007 i686
Build Date: 26 July 2007
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 17 23:22:54 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "SyncMaster"
(**) | |-->Device "ATI Technologies Inc RV350 AR [Radeon 9600]"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "stylus"
(**) |-->Input Device "cursor"
(**) |-->Input Device "eraser"
(==) FontPath set to:
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(**) Extension "Composite" is disabled
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e5980
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.3
 X.Org Video Driver: 1.2
 X.Org XInput driver : 0.7
 X.Org Server Extension : 0.3
 X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 ABI class: X.Org Video Driver, version 1.2
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0282 card 1043,80a3 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:00:1: chip 1106,1282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:2: chip 1106,2282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:3: chip 1106,3282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:4: chip 1106,4282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:7: chip 1106,7282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,b188 card 0000,0000 rev 00 class 06,04,00 hdr 01
(II) PCI: 00:0b:0: chip 109e,036e card 0000,0000 rev 11 class 04,00,00 hdr 80
(II) PCI: 00:0b:1: chip 109e,0878 card 0000,0000 rev 11 class 04,80,00 hdr 80
(II) PCI: 00:0d:0: chip 10b7,9200 card 10b7,1000 rev 74 class 02,00,00 hdr 00
(II) PCI: 00:0e:0: chip 1102,0002 card 1102,8040 rev 05 class 04,01,00 ...

David Jaša (dejv) wrote :

I can confirm this bug on integrated ati xpress 1250 on HP Compaq 6715s notebook.

Dell Inspiron E1505 Notebook
ATI Mobility Radeon X1300
1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
Ubuntu Gutsy Herd 4


Installed restricted driver from command line... These are my logs and outputs after I did this and was able to get into Gnome...

1 comments hidden view all 175 comments
Timo Aaltonen (tjaalton) wrote :

If anyone of you is using gutsy at the moment, please test a new xserver version available here:


It has a patch which should fix this for good.

Bryce Harrington (bryce) on 2007-08-23
Changed in xorg-server:
status: Incomplete → Fix Committed
Tormod Volden (tormodvolden) wrote :

Tested the -12 xserver and vesa will still not start on ATI X700. Tried to debug a little with gdb:
- segfaults at line 683 in vesa.c
- the pScrn->display->modes linked list is corrupted, ->next is invalid (see gdb session)

1 comments hidden view all 175 comments
Andrea Colangelo (warp10) wrote :

@ Timo Aaltonen: Sorry, but your fix is not working for me.

I downloaded and launched (in live mode) Tribe 5 on my Inspiron 6400 (Ati Radeon Mobility X1400, my hardware isn't changed at all).
As I thought, X is not working yet. Anyway, the behaviour is just slightly changed: as you can see in the log, I have not either a backtrace information or a clear error message.

I installed Timo's xserver (I made a dpkg -i xserver-xorg-*) but nothing is changed. I attach the Xorg.0.log both before and after the upgrade.

Anyway, the usual sudo dpkg-reconfigure xserver-xorg allowed me to start x, altough with a poor 1024x768 resolution, as always.

2 comments hidden view all 175 comments
Timo Aaltonen (tjaalton) wrote :


You managed to get the server working by reconfiguring it, so the patch _does_ work :) Poor resolution is because of vesa, it doesn't support widescreen modes.

Andrea Colangelo (warp10) wrote :

Well, I really hope this is true, but since my original report for this bug I said that reconfiguring xserver allows to start x, so nothing looks changed to my non_developer & non_X_expert eyes. :)
Probably a good test would be to launch ubuntu live with your patched server. Do you have any indications about the best way to do this?

Timo Aaltonen (tjaalton) wrote :

Andrea: If that's the case, then your issue is different from this one. There are reports that the live-cd doesn't generate a working config, but after reconfiguration things are working...

Andrea Colangelo (warp10) wrote :

Timo: probably my poor english is not helping to understand each other.
Anyway, what I say is that when I reconfigure xserver-xorg I can start X, and this is true both if the standard xserver is installed and if I upgrade to your patched xserver. But I noted that launching X, using the original xorg.conf, after installing your patched xserver doesn't work, so it appears to me that your patch doesn't change the situation. I am not an expert about X, but I believe that it could be interesting to see what happens if I boot a live-cd with your patched xserver.

GabrielGrant (gabrielgrant) wrote :

Timo: I don't think Andrea's issue could be "different from this one" - Andrea is the original reporter :)

Perhaps some other people have other issues that are addressed by the patch, but if it doesn't fix Andrea's original problem that would mean that their bugs have been misdiagnosed and should be moved to separate reports.

...just to clear things up...

Thanks a lot for all of your work towards fixing this,

Matt Myers (msquared-gmail) wrote :

I don't know if it helps at all, but I installed the x86_64 version of 7.04 on my T60 and it worked fine.

Petr Nemec (nemecpe) wrote :

I am experincing troubles with this "Failed to start the X server" since Ubuntu 7.04 on my laptop with ATi Mobility Radeon X1600.
I tried todays gutsy daily-live(20070825), where "xorg-server 2:" already presents, but the problem still remains.

I was hoping this would be fixed by tribe 5, but I am still having the same problem with tribe 5 as well.

Dell Inspiron E1505 Notebook
ATI Mobility Radeon X1300
1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
Gutsy Tribe 5

Tormod Volden (tormodvolden) wrote :

I noticed that my trace with X700 in comment #142 seems to be the same as the one from András in comment #98 (from April): crash in same function and line number. But in the original report there is no crash and the server log is different. So this must be another issue, although one may trigger/expose the other in some situations. So I opened bug #135218 for our crash issue.

Glen (synergy-oz) wrote :

I wouldn't get your hopes up, I've been waiting since Feburary for this bug
to be fixed.
Perhaps 8.03 with the next version of xorg.

On 8/28/07, brokencrystal.com <email address hidden> wrote:
> I was hoping this would be fixed by tribe 5, but I am still having the
> same problem with tribe 5 as well.
> Dell Inspiron E1505 Notebook
> ATI Mobility Radeon X1300
> 1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
> Gutsy Tribe 5
> --
> [regression] 7.2 broke vesa: "No matching modes found"
> https://bugs.launchpad.net/bugs/89853
> You received this bug notification because you are a direct subscriber
> of the bug.

Tormod Volden (tormodvolden) wrote :

Please try the new xserver-xorg-video-vesa 1.3.0-1ubuntu5 now in Gutsy.

Petr Nemec (nemecpe) wrote :

Tormod Volden: With daily-live 20070831 the X server finally started without a problem on my Mobility Radeon X1600.

Timo Aaltonen (tjaalton) wrote :

Petr: that's good news, hopefully it works for others, too :)

Changed in xorg:
status: New → Fix Committed

Where do I get the daily-live build iso? (Path)

I will try it and let you know.

garrin (garrinm) wrote :

Hey I just tried the daily build and it worked for me as well. Great job thanks to all the devs who helped fix this bug... it had been bugging me for quite a while.

By the way I have an Inspiron 6400 with Radeon X1300 (128mb).

Andrea Colangelo (warp10) wrote :

I tried the daily-live build and for the first time since Herd 4 I went straight to the Desktop without X troubles. Wrong resolution, but at least aI have X working.
Looks like we can finally close this bug.

Thanks to everyone who took care for this bug. It's people like you that make strong our community.

Tal Shachar (shachtal) wrote :

for the first time
since ubuntu 6.04
i can finally install the system without jumping through hoops!!!!
thanks to the daily 31/08 iso of ubuntu gutsy gibbon

my system is lg P1 pro express dual, running on ati radeon x1400 with a widescreen

the resolution seems to work fine btw
which is sth that was fucked up in previouse verssions as well :)

thank you all crazy programers that know more than me on how to fix these things

now if only my agre modem and soundcard would work fine .... :)

OK, now will it support my native resolution? The last time I checked, I didn't see 1280 by 800 even listed...

Dell Inspiron E1505 Notebook
ATI Mobility Radeon X1300
1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
Gutsy Tribe 5

Matthew Garrett (mjg59) wrote :

No. The vesa driver will only support vesa modes, which doesn't include any widescreen modes.

Do we need to do a bug report, or is one already in progress? Maybe they will just consider this a wishlist item...

Changed in dell:
status: New → Fix Committed
Bryce Harrington (bryce) wrote :

Thanks for confirming that Timo's patch to -vesa fixed the issue. Closing as such.

Changed in xorg:
importance: Undecided → High
status: New → Fix Released
Bryce Harrington (bryce) wrote :

By the way, for those wishing to participate in more in-depth testing of new drivers for Radeon and other chipsets, you may wish to join the Ubuntu X Testing Forum at http://ubuntuforums.org/showthread.php?t=490982. We're currently analyzing the xrandr-enabled 2.7.192 -ati driver, and hope to start testing AMD's new driver as soon as code becomes available.

Timo Aaltonen (tjaalton) wrote :

Closing for the other components as well!

Changed in xserver-xorg-video-vesa:
status: Fix Committed → Fix Released
Changed in xorg-server:
assignee: tepsipakki → nobody
Timo Aaltonen (tjaalton) on 2007-09-11
Changed in xorg-server:
status: Fix Committed → Fix Released
Changed in dell:
status: Fix Committed → Fix Released
Djainette (djainette) wrote :

I have a samilar problem with Ubuntu Hardy alpha 5 :

(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found


Devils_chile (devils-chile77) wrote :

I had the same problem in Ubuntu Intrepid Ibex when booting form live CD or USB.

The video card is an ATI HD2400 Mobility Radeon in a Toshiba A200 laptop.

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Changed in somerville:
status: New → Fix Released
no longer affects: dell

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305977

no longer affects: somerville
Displaying first 40 and last 40 comments. View all 175 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.