Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect

Bug #3731 reported by Evandro Pastor
468
This bug affects 20 people
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Fix Released
High
Ubuntu-X

Bug Description

I'm upgrade my system to ubuntu 5.10, after that, xorg can't load the correct resolution of the monitor ( 1024 x 768 ). I'ts only load 640x480. I've used dpkg-recunfigure xserver-xorg, and insert the correct values, but don't work. The system is a Samsung 753dfx and a gforce mx 200 32mb.

[Update]
A lot of people have reported this same bug. Symptoms include:

  * Your hardware supports a variety of resolutions, but Ubuntu only runs in 640x480, 800x600, and/or 1024x768. If you have all three resolutions, but expect more, you are likely seeing bug 27667, bug 49827, or bug 94994.
  * In the "Monitor" section of /etc/X11/xorg.conf, your monitor is listed as "Generic Monitor", with HorizSync and VertRefresh rates that do not match your monitor
  * `sudo xresprobe <driver>` fails to work, or does not return accurate information for your hardware. (You can find your driver by looking in /etc/X11/xorg.conf for the line "Driver ..." It will be something like 'ati', 'nv', 'nvidia', etc. If you are using this on a laptop, run `sudo xresprobe <driver> laptop`. Also run `sudo ddcprobe` - if you see "edidfail" then you are experiencing bug 94994.

One work-around for this bug is to edit /etc/X11/xorg.conf and replace the rates with ones that match your monitor. The section should look something like this:

Section "Monitor"
        Identifier "Generic Monitor"
        VendorName "SNY"
        ModelName "SDM-S91"
        Option "DPMS"
        HorizSync 28-80 # Important: Use horizontal frequency for your monitor
        VertRefresh 48-75 # Important: Use vertical frequency for your monitor
EndSection

Your monitor's documentation will tell you what the frequencies are. It's typically on a data sheet in the back of the book titled "Input Signal" or similar. If you don't have the printed manual, you can usually also find it on the manufacturer's website.

Alternatively, you can try running `sudo dpkg-reconfigure xserver-xorg` and specifying the refresh rates through that interface, if you wish to avoid hand editing config files. Note that this will replace your xorg.conf file entirely.

If you're running Gutsy, then you can also try the Screen and Graphics GUI admin tool, which lets you reconfigure your xorg.conf in a graphical manner.

Tags: iso-testing
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

You would probably need to attach /var/log/Xorg.0.log (or the pertinent part if you know what to look for) in order to help debug this...

Also do you have a hardware id (System Tools -> Ubuntu Device Database)?

Revision history for this message
Evandro Pastor (evandrolinux) wrote :
Download full text (36.6 KiB)

I'm get a log file:

X Window System Version 6.8.2 (Ubuntu 6.8.2-77 20051010174523 <email address hidden>)
Release Date: 9 February 2005
X Protocol Version 11, Revision 0, Release 6.8.2
Build Operating System: Linux 2.6.10 i686 [ELF]
Current Operating System: Linux pai 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686
Build Date: 10 October 2005
 Before reporting problems, check http://wiki.X.Org
 to make sure that you have the latest version.
Module Loader present
OS Kernel: Linux version 2.6.12-9-386 (buildd@rothera) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:14:36 BST 2005 T
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: Mon Oct 31 18:03:08 2005
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "SyncMaster"
(**) | |-->Device "NVIDIA Corporation NV11 [GeForce2 MX/MX 400]"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(WW) The directory "/usr/share/X11/fonts/cyrillic" does not exist.
 Entry deleted from font path.
(WW) The directory "/usr/share/X11/fonts/CID" does not exist.
 Entry deleted from font path.
(WW) `fonts.dir' not found (or not valid) in "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID".
 Entry deleted from font path.
 (Run 'mkfontdir' on "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID").
(**) FontPath set to "/usr/share/X11/fonts/misc,/usr/share/X11/fonts/100dpi/:unscaled,/usr/share/X11/fonts/75dpi/:unscaled,/usr/share/X11/fonts/Type1,/usr/share/X11/fonts/100dpi,/usr/share/X11/fonts/75dpi,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.2
 X.Org Video Driver: 0.7
 X.Org XInput driver : 0.4
 X.Org Server Extension : 0.2
 X.Org Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
 compiled for 6.8.2, module version = 1.0.0
 Module class: X.Org Font Renderer
 ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
 compiled for 6.8.2, module version = 1.0.0
 ABI class: X.Org Video Driver, version 0.7
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0305 card 1458,0000 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,8305 card 0000,0000 rev 00 class 06,04,00 hdr 01
(II) PCI: 00:07:0: chip 1106,0686 card 1106,0686 rev 40 class 06,01,00 hdr 80
(II) PCI: 00:07:1: chip 1106,0571 card 0000,0000 rev 06 class 01,01,8a hdr 00
(II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00
(II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 16 class 0c,03,00 hdr 00
(II) PC...

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Looks like your monitor said it couldn't do it because the horizontal sync rate was out of its range. You would have to *attach* (via Add Attachment at the right) your /etc/X11/xorg.conf for further inspection (but it's hard to know whether all that much more can be done)

Changed in xorg:
assignee: nobody → daniels
Revision history for this message
Evandro Pastor (evandrolinux) wrote :
Download full text (3.3 KiB)

There is my xorg.conf:

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
    FontPath "/usr/share/X11/fonts/misc"
    FontPath "/usr/share/X11/fonts/cyrillic"
    FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
    FontPath "/usr/share/X11/fonts/75dpi/:unscaled"
    FontPath "/usr/share/X11/fonts/Type1"
    FontPath "/usr/share/X11/fonts/CID"
    FontPath "/usr/share/X11/fonts/100dpi"
    FontPath "/usr/share/X11/fonts/75dpi"
        # paths to defoma fonts
    FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
    FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID"
EndSection

Section "Module"
    Load "GLcore"
    Load "bitmap"
    Load "dbe"
    Load "ddc"
    Load "dri"
    Load "extmod"
    Load "freetype"
    Load "glx"
    Load "int10"
    Load "record"
    Load "type1"
    Load "v4l"
    Load "vbe"
EndSection

Section "InputDevice"
    Identifier "Generic Keyboard"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "abnt2"
    Option "XkbLayout" "br"
    Option "XkbVariant" "abnt2"
    Option "XkbOptions" "abnt2"
EndSection

Section "InputDevice"
    Identifier "Configured Mouse"
    Driver "mouse"
    Option "CorePointer"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "ImPS/2"
    Option "ZAxisMapping" "4 5"
EndSection

Section "Device"
    Identifier "NVIDIA Corporation NV11 [GeForce2 MX/MX 400]"
    Driver "nv"
    BusID "PCI:1:0:0"
    VideoRam 32768
EndSection

Section "Monitor"
    Identifier "SyncMaster"
    Option "DPMS"
EndSection

Section "Screen"
    Identifier "Default Screen"
    Device "NVIDIA Corporation NV11 [GeForce2 MX/MX 400]"
    Monitor "SyncMaster"
    DefaultDepth 24
    SubSection "Display"
        Depth 1
        Modes "1024x768"
    EndSubSection
    SubSection "Display"
        Depth 4
        Modes "1024x768"
    EndSubSection
    SubSection "Display"
        Depth 8
        Modes "1024x768"
    EndSubSection
    SubSection "Display"
        Depth 15
        Modes "1024x768"
    EndSubSection
    SubSection "Display"
        Depth 16
        Modes "1024x768"
    EndSubSection
    SubSection "Display"
        Depth 24
        Modes "1024x768"
    EndSubSection
EndSection

Section "ServerLayout"
    Identifier "Default...

Read more...

Revision history for this message
teaker1s (teaker1s) wrote :

just a suggestion but did you use advanced and set monitor h and v resolutions to what the spec on your monitor is?

Revision history for this message
teaker1s (teaker1s) wrote :

you may or may not be aware that default ubuntu uses nv driver but there are seperate opengl nvidia drivers current and legacy which may also solve your problems regarding resolution

Daniel Stone (daniels)
Changed in xorg:
assignee: daniels → nobody
Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

could you please exit from X and run "xresprobe nv" as root or "sudo xresprobe nv" and add the output to this bug?

afaik this bug has been fixed already in dapper.. also testing it would be ideal.

Fabio

Changed in xorg:
status: Unconfirmed → Needs Info
Revision history for this message
Evandro Pastor (evandrolinux) wrote :

Sorry forgives for the delay, I had a problem with my PC that I only decided today. Follow the exit of xresprobe nv:

id: SyncMaster
res: 1280x1024 1024x768 832x624 800x600 720x400 640x480
freq: 30-71 50-160
disptype: crt

Revision history for this message
Carthik Sharma (carthik) wrote :

Assigning to Ubuntu-x-swat team.

Original Reporter, could you please confirm that this bug has been fixed in Dapper latest?

Thank you for reporting this bug.

Changed in xorg:
assignee: nobody → ubuntu-x-swat
Revision history for this message
Jerome S. Gotangco (jsgotangco) wrote :

Please confirm if this still persists in Dapper Beta. If we don't get a reply sooner, we'll assume this is fixed already.

Revision history for this message
Evandro Pastor (evandrolinux) wrote :

I can't say that. The system are in production ambient, i can,t test in this machine. :( When I upgrade to next version, I post a result.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

I can't see anywhere in the log or in the config that something is wrong. Do you actually have the monitor turned on when the machine is booting or X starting?

Fabio

Revision history for this message
Felix Delattre (delattre) wrote :

Still have this kind of problem with dapper drake flight7. Using a IBM Thinkpad A31p ATI FireGL 7800 M7 with 15" Display. Same problem with original xorg.conf, but in my one changed somethings, which i read in the internet.

http://www.delattre.de/xorg.conf
http://www.delattre.de/Xorg.0.log

Sorry for the extern links, but i havent seen the upload option.

Revision history for this message
Felix Delattre (delattre) wrote :
Revision history for this message
Master Ar2ro (ar2ro) wrote :

I've encountered this bug with Feisty Herd 3 LiveCD. It seems thought that it only appears when I reboot from Windows XP to LiveCD. When I reboot from my Edgy installation, the LiveCD correctly detects and sets up the resolutions.

Revision history for this message
3zero2 (bugeja) wrote :

I have encountered this bug on dapper, edgy and now also on feisty herd 5.

My hardware is an Nvidia GeForceFX 5700 with a CMV CT-722D monitor.

My tft is capable of 1280x1024 but ubuntu only sets it to 1024x768. Running sudo dpkg-reconfigure -phigh xserver-xorg and choosing the correct resolutions fixes the problem.

Contact me if you need more info.

Revision history for this message
Bryce Harrington (bryce) wrote :

It sounds like the problem here is that dpkg-reconfigure xserver-xorg is failing to generate correct information for the monitor section of the config file.

In each user's case, the h/v frequencies were either missing or set incorrectly. Xorg had difficulty determining a proper mode to use, and fell back to 640x480.

3zero2, I suspect your issue is completely unrelated, since you are able to achieve 1024x768 unlike the original bug reporter. Many others have reported that Ubuntu's Xorg settings max out at 1024x768, so I think your issue is simply a duplicate of that one. Thanks for offering to collect more info, but I think this one is already sufficiently well reported. Hopefully we'll figure out a fix soon.

Bryce Harrington (bryce)
Changed in xorg:
importance: Medium → High
status: Needs Info → Confirmed
Revision history for this message
Tony Pursell (ajpursell) wrote : Re: Xorg resolution falling back to 640x480 when h/v freqs incorrect

There is a related problem with upgrading. I upgraded from dapper via edgy to feisty. After the upgrade to edgy the splash screen did not display and my HP vs17x monitor complained about the settings. However, the login sreen displayed OK in my default 1024x768 resolution. Upgrading to feisty made no difference. The work around was to add a vga= parameter in GRUB. By the way, I checked my Xorg configuration and it was unchanged from dapper. I notice that the slash screen has changed - just a progress bar instead of a scrolling list of boot tasks.

Revision history for this message
Bryce Harrington (bryce) wrote :

I did some more research into this bug; I'll update the description with the findings.

Tony, those splash screen issues may be unrelated to this particular bug, especially if your Xorg config file has not changed. Could you look through launchpad and see if there is a bug specifically for that?

Changed in xorg:
importance: High → Critical
Bryce Harrington (bryce)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

Some data points from my own experimentation with hardware at hand:

Did NOT detect monitor on an Intel x86_64 box with nVidia Quadro NVS 285 card that has a VGA "splitter cord" that makes the card dual-head capable. It was tricky getting xinerama working on this card so I'm not surprised it had issues here.

DID detect a Sony LCD monitor on a Dell XPS x86 system with a Radeon R350. It was connected to the R350's VGA port. Did NOT detect another similar Sony LCD monitor connected to the Radeon's DVI port. I used a DVI-to-VGA adapter since the second monitor is VGA. I don't know if it's DVI or the adapter, or if xresprobe only detects a single monitor.

Revision history for this message
Bryce Harrington (bryce) wrote : Re: [Bug 109483] Re: Fiesty Fawn screen resolution bug at install

One thought would be for purposes of installation to temporarily swap
with one of those other monitors, if the resolution issue is too
problematic. Then after installation is done just re-swap the
monitors, and fix the /etc/X11/xorg.conf file with the Monitor section I
indicated.

I don't think xresprobe is installed by default so after installation
you might need to add it via:

  sudo apt-get install xresprobe

xresprobe does indeed need to get replaced ultimately. Our tentative
plan is to use Xorg's builtin 'xrandr' system for automatic monitor
detection. However, we've not done much testing of it, but it's easy to
test by just moving aside your xorg.conf. I.e.:

  sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.orig

Then restart X and see what happens. If X fails to work properly, then
log into a console window (Ctrl-Alt-F1) and then do:

  sudo mv /etc/X11/xorg.conf.orig /etc/X11/xorg.conf

The times I've experimented with this, it has worked very well, however
I would like to hear from other users if it also works okay for them or
not.

Thanks,
Bryce

Bryce Harrington (bryce)
description: updated
Revision history for this message
Olivier (olivier-lacroix) wrote :

Hi,
as this bug seems to be the one where to gather resolution autodetection problems, here I go.

Feisty failed to detect well the native resolution (1400x1050) of my laptop screen. That is strange because xresprobe gave the right one. I have no idea what went wrong.

It's an asus laptop based on a centrino dothan platform with an X600 graphic card

just tested it : xrandr got it right.

If you need any debug info, just ask for it.

Olivier

Revision history for this message
Christian Pernegger (fallenguru) wrote :

Just wanted to add that this doesen't have much to do with the H/V-freqs being wrong - having no freqs in xorg.conf has the same effect, even though the X server reads the monitor's EDID info correctly.

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Bug posted 109483, a possible dupe of 3731.

Ref:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/109483

Related Gutsy Gibbon idea suggestion thread:
http://ubuntuforums.org/showthread.php?t=423745

I am ready to test possible solutions as this bug affects my current hardware. I await to be advised what to do to assist.

Cheers.

Revision history for this message
Michal Suchanek (hramrach) wrote :

I would like to add that X often does not detect the monitor either. In some cases xresprobe or similar can read the monitor info but X cannot. Sometimes it is the other way around. I suspect there are some marginal setups that require several retries/longer timeouts than usual.

And there are several ways to read the info. One can usually query bios or read the info from the monitor. Sometimes one way works and other returns nothing or nonsense.

And reading the info is not always reliable. Even if the monitor is connected and turned on.
I just started X about a dozen times, and once it came in 800x600@60. Just killing the server and starting a new one fixed the problem.

Some drivers in X do not rely on the info returned from the monitor. In the ideal case a xorg.conf with no monitor settings should work. However, some graphics card drivers require a special option to actually use the information read from the monitor.

Revision history for this message
Bryce Harrington (bryce) wrote :

bug 91292 shows similar behavior with a cluster of bugs against the nvidia restricted driver. Several have reported that the failed monitor detection only showed up after upgrading to Feisty from earlier versions, suggesting there is a software change involved (perhaps xresprobe went missing, or a driver version changed, or the new xorg 7.2, or...?)

Revision history for this message
Bryce Harrington (bryce) wrote :

Also see bug 8177 regarding vbetool. Also has some good background into the ddcprobe situation and describes some of the amd64 portability problems.

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

I have manually edited the xorg.conf many times, with many variations. Yes setting the H and V refresh rates and modes will eventually enable one of a few viewable outcomes, but such is easily broken.

For example, I went to see the 3d cube, Compiz, installed/enabled the drivers, reboot and I was back to 800x600 50Hz on a 19" CRT. No way around that other than to lose those drivers. They ignored xorg.conf completely.

I have also tested xresprobe, but without success.

Xorg 7.3 is slated to be released in May 2007 and that is said to not use a xorg.conf at all.

Also other distros have auto detection methods that work (from what I have learned), such as suse.

7.04 doesn't work at all for me because I need a full range of screen resolutions, color bit depth and refresh rates - everything my hardware can do, before I can actually view 7.04 to see what it is like.

Bryce, when you have some actual software solution, let me know and I will test it.

Revision history for this message
Hans van Esdonk (hans-excilas) wrote : Re: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect

I remember that after installing the crt was in the 1024 x 768 mode
(after a restart) I played with the "desktop effects" and switched those
off again. After some time the crt switched spontaneously to 800 x 600
and in the menu only this mode and 640 x 480 was available. The
"xresprobe install" solved the problem for some reason I don't
understand. Till now I work in the 1024 x 768 mode without problems.
I also tried to change the config but it looked if it didn't accept the
changes. At the moment in the /var/log/Xorg.0.log file shows my monitor
type (daewoo 518X) so I'm satisfied

Hans van Esdonk

Op vrijdag 27-04-2007 om 00:13 uur [tijdzone +0000], schreef Chris:
> I have manually edited the xorg.conf many times, with many variations.
> Yes setting the H and V refresh rates and modes will eventually enable
> one of a few viewable outcomes, but such is easily broken.
>
> For example, I went to see the 3d cube, Compiz, installed/enabled the
> drivers, reboot and I was back to 800x600 50Hz on a 19" CRT. No way
> around that other than to lose those drivers. They ignored xorg.conf
> completely.
>
> I have also tested xresprobe, but without success.
>
> Xorg 7.3 is slated to be released in May 2007 and that is said to not
> use a xorg.conf at all.
>
> Also other distros have auto detection methods that work (from what I
> have learned), such as suse.
>
> 7.04 doesn't work at all for me because I need a full range of screen
> resolutions, color bit depth and refresh rates - everything my hardware
> can do, before I can actually view 7.04 to see what it is like.
>
> Bryce, when you have some actual software solution, let me know and I
> will test it.
>

Revision history for this message
tomas erlendsson (erlendsson-tomas) wrote :

had a buddy with this problem in his 7.04 and fixed the problem by going to system settings..monitor and display...addmin mode..hardware...monitor configure...chose generic...click the right resolution for your screen ok and restart Xserver....sorry about not applying you with tecnical info I am a complete newcomer to the data world, but this did fix his problem,,, you might want to find your own monitor in there.....we could not find his so we choose generic...

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Here is a related thread to discuss this further, to complement this launchpad Bug #3731 reporting:

http://ubuntuforums.org/showthread.php?t=423745

Revision history for this message
jamings (jamings) wrote :

Hi
My name is Ed <email address hidden>.

I had a problem installing version 7.0. I could not get a resolution greater than 640 x 480. This prevented me from installing the system, therefore I could not do any of the tweaks that you folks had suggested. My solution was to upgrade my video card and now get a resolution of 1024 x 768. I was able to install the system and am using it at present. Thanks for all the support and hope this info is helpful.

Ed

Revision history for this message
Bryce Harrington (bryce) wrote :

For Feisty, xresprobe is not included in the default installation. In theory, this should not be an issue for most people, however I think for people who don't have xresprobe installed, if they reconfigure Xorg then the new xorg.conf file could result in incomplete monitor detection, and thus lead to this bug. This could also occur if the user installed a new monitor or video card and re-ran `sudo dpkg-reconfigure xserver-xorg` without first installing xresprobe. It could also occur if a user upgrades from Edgy or Dapper to Feisty, and xresprobe gets uninstalled, and then the user reconfigures xorg. As I understand, this was a unique change for Feisty, and wouldn't affect Edgy or Dapper users since as I understand xresprobe was installed by default in those.

For gutsy we've altered things such that xresprobe is once again installed by default, so behavior should at least return to where it was with Edgy and Dapper. In at least one dupe of this bug, having xresprobe present seems to have helped. See bug 109908.

However, this change only gives us a partial fix; I know there are additional problems with xresprobe that will crop up even with it installed.

Revision history for this message
Bryce Harrington (bryce) wrote :

In bug 94673, this monitor non-detection is occurring intermittently - sometimes it detects correctly, sometimes it sets it as generic monitor. Have others seen intermittent behaviors like this, from boot to boot?

Revision history for this message
Michal Suchanek (hramrach) wrote :

Yes, with a rv100 card and Sony G200 monitor. It was not from boot to boot but from X start to X start. That is probably why Windows keep the resolution settings when no screen is detected. It may be turned off, disconnected, or the detection just might have failed.

Revision history for this message
Bhavani Shankar (bhavi) wrote :

Yes this happens to me also when I changed my card from Igma to Nvidia 6600 GT

Revision history for this message
Vedran Rodic (vrodic) wrote :

I believe that the same class of problems are causing many monitor resolution/refresh rate problems as listed in bugs 50048, 27667 (these are the bugs I made comments on) and probably many more. The problems with the edid data.

The new Xorg server should be able to query monitor by itself for DDC edid info about it's capatibilities, without ddcprobe. This functionality works for me if I leave out monitor specific information from my Xorg.conf like this:
Section "Monitor"
    Identifier "Generic Monitor"
    Option "DPMS"
EndSection

In the edid there should be data for the recommended resolution and refresh rate. The problem is however that some monitors have this data wrong (so you don't get the right resolution or refresh rate), or the checksum of the complete data wrong (so you don't get the edid data used by X at all). Either way, could you send the output of the get-edid > yourmonitormakeandmodel.edid as attachment to this bug, and possibly the xorg mailing list, so we can see what's wrong with the data and add a quirk for it in the Xorg code? get-edid is in the read-edid package, and it's output can be piped to parse-edid to create the Xorg.conf monitor section). I'm not sure why the checksum for edid data for my monitor is incorrect, it's probably a quirk of my monitor, but for other cases where edid data is different on multiple runs of get-edid or Xorg, it might be best to permanently store this data to be used if nothing valid is detected on subsequent runs.

 If this gets done in time, it's quite possible that gutsy will finally have good out of the box monitor autodetection support.

Revision history for this message
Tony Pursell (ajpursell) wrote :

I have attached output from get-edid for my HPvs17x monitor as requested.

Since getting this problem with Dapper (Bug #68905), I have upgraded to Edgy. With Edgy I experienced a similar problem. During the boot sequence the monitor complained about the settings it was given (it asks for 1280x1024 @ 60Hz) and did not display the splash screen. I cured it by adding vga=791 to the defoptions in grub. Note, this was not a problem with Dapper.

Revision history for this message
Vedran Rodic (vrodic) wrote : Re: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect

@Tony, Your edid seems to be correct, and X should use it without problems.

Video mode setting code for the OS splash screen is in the kernel, and
we hope it will be solved when (and if) the mode setting code is moved
to the kernel. Regardless of that, current kernel code could be
patched, but I'm not currently looking into that.

Revision history for this message
Bryce Harrington (bryce) wrote :

An early preview about a GUI config tool we've been working on to help address this problem, since I know many people are having this problem and wondering what the plan is:

http://people.ubuntu.com/~bryce/BulletProofX/

This is not a true fix for the root cause of this bug, however it is going to be a better workaround than having to manually hand-edit your xorg.conf. The above link shows the tool in use when Ubuntu has completely failed to generate a working xorg.conf, and provides a failsafe environment where the user can select monitor/device settings.

The displayconfig-gtk tool will also be available from within Ubuntu's System menu, to allow re-configuration once Ubuntu has launched.

Neither of these capabilities are implemented in Gutsy yet, but should be within the coming weeks; I'll update here once there is something that can actually be tried out.

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Keep up the good work Bryce. Looks great so far!

Revision history for this message
Michal Suchanek (hramrach) wrote :

Looks good, this is certainly an improvement over the "X broke, you are to keep the pieces" dialog.

I would suggest several other things:

 - when I set the driver to "iwantaponny" (or physically change the card) I would like the tool to automatically remove the card section and generate a new one, and only bug me if X fails to start after that.

 - an option (default on) to save screen data, and reuse it when screen is not detected. This could be done as a gdm (or similar) script once X starts. To avoid the need to start in some sort of VGA failsafe mode in most cases this could have several modes
   1) detection working (and used by the driver, some have it off by default) - all OK, save data
        - if the monitor is not in a database of known monitors, offer the option to send the data somewhere for inclusion. The user should fill in the manufacturer and model because the DDC data often says something else. This probably should be the default only in beta distributions. When sent, the monitor should be added to the local database or some whitelist so that the script does not ask again. Perhaps the script could even ask if the manufacturer/model in the database and the detected parameters are correct.
   2) detection not working, saved data present - offer the option to use the saved data
        - once X is restarted ask to make the monitor data default regardless of autodetection - should be hard to select when the screen is not working
   3) detection not working - offer a selection of monitors to choose from + some generic types like 19" LCD (1280x1024) or 17" CRT (1024x768)
        - on restart the same as 2)

Note that many monitors that can be detected on one card would fail on another, and some cards may be completely broken in this regard. Thus the semi-automatic building of monitor database could be helpful, and monitors that report bad data could be singled out - users can send the saved data when stuff breaks.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Bryce:
This sounds similar to what was proposed in https://wiki.ubuntu.com/XserverFailover

Revision history for this message
Tony Pursell (ajpursell) wrote :

Bryce:

Will your BulletProofX work for the Live CD? In my original Bug #68905 the big problem for me was getting my hard drive repartitioned because I couldn't run gparted in the low resolution. If you remember, I was lucky to find a Gparted live CD which had a wide range of video setup options.

Revision history for this message
Bryce Harrington (bryce) wrote :

Michal: For automatic device detection, the plan is to let xorg do full autodetection of both the monitor and the graphics card. That is still a work in progress (although it already works well for many configurations). This is actually considered the *true* fix for this bug 3731, and I'm really looking forward to seeing how well it works. You can test it by commenting out the Device and Monitor section in your xorg.conf and the two corresponding lines in your ServerLayout, starting X, and see if it picks up the right device, card, and resolution rates. This should work for Gutsy, and *maybe* in Feisty, but there's still a lot of hardware that probably won't get detected right.

Thanks for the suggestion to save the screen settings, that sounds like it could be useful. I'll experiment with implementing that once I've got more of the basics in place.

Sitsofe: thanks, I hadn't seen that spec before; it's got a number of interesting links for me to check out. I'd noticed a few proposals for fallback modes in the wiki, so this is definitely an idea that's been kicking around a while.

Tony: Actually the plan for the LiveCD situation is rather than pop into the failsafe mode, to just go ahead and boot the LiveCD with vesa or vga or fbdev, so BulletProofX won't be relevant in that situation. However, the displayconfig-gtk tool will be present in the Admin menu, so if you got booted into a low resolution, you can use that to select your monitor/device/resolution, test it with the Test button, and then go into the installer like normal. I hope the installer will then notice you've already configured xorg and reuse your changes, but that may take some work to iron out the kinks.

Everyone: If you're getting these emails from 3731 (perhaps via a dupe bug) and don't want them, a helpful reminder: If you go to bugs.launchpad.net and log in, you can see a list of bugs. Each bug has an 'unsubscribe' link you can use to stop getting the email from that bug.

Revision history for this message
Nick_Hill (nick-nickhill) wrote : Compaq N1000v wrong resolution with Gutsy

Either booting from CD or from install, the screen is set at 800x600. This gives a black border on the left and the screen folding from top to bottom. Not very elegant.

I have tried with xorg.conf removed, same effect, so it appears auto-detection isn't functioning as expected.

lspci -v:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
        Subsystem: Compaq Computer Corporation Unknown device 004e
        Flags: stepping, 66MHz, medium devsel, IRQ 11
        Memory at 48000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 3000 [size=256]
        Memory at 40400000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at 40420000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2

Attached: Xorg.0.log from Compaq Evo N1000v booted with Gutsy Tribe 2 live CD

Revision history for this message
Nick_Hill (nick-nickhill) wrote :

>This gives a black border on the left
Sorry, the black border is on the right.

The resolution should be 1024x768 preferably 24 or 32bpp.

According to the xorg.log, there is DDC data to establish screen resolution and DPI (I am experiencing DPI issues on Gutsy on other machines):

(II) RADEON(0): clock: 65.0 MHz Image Size: 286 x 214 mm
(II) RADEON(0): h_active: 1024 h_sync: 1048 h_sync_end 1184 h_blank_end 1344 h_border: 0
(II) RADEON(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 806 v_border: 0

Revision history for this message
Jeremy Melanson (jmelanson) wrote :

I fixed the "tiling" issue with the compaq evo n1000v.

I had to specify HorizSync and VertRefresh in my "monitor" definition:

Section "Monitor"
Identifier "Monitor0"
VendorName "LGP"
ModelName "6e54"
Option "DPMS"
HorizSync 31.5-90.0
VertRefresh 59.0-60.0
EndSection

After I did this, everything was back to normal.

Revision history for this message
Michal Suchanek (hramrach) wrote :

Bryce: The X autodetection is not a solution for now. It is so poorly designed it is unusable.

It does not work by commenting out sections in the config file. You have to *REMOVE* the config file *COMPLETELY*.

This means that many settings for which there are no reasonable defaults break.

However, I tried it for the sake of experimentation when I was configuring X for Ati Radeon 9200 + Sony G200. The readouts from the card are complete, the monitor is fully identified including all the modes. X says the first detailed timing is the preferred mode in the log but it chooses some 60Hz mode for this CRT monitor. It probably chooses the largest over the one marked preferred or one that has reasonable refresh rate.

Even if it worked this way of configuration is useless because it does not allow to specify *anything* in the config file (keyboard layout, server options, dri options, font paths, graphics driver options, ..). Many of these options could be set or worked around in gdm scripts but some cannot.

For one, on Matrox cards the default is hardware cursor which is broken. Another recurring problem is the option to use DDC readings defaulting to off for some drivers.

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Hi Bryce,

Any news about this project?

Anything to test yet?

Chris

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

I just tested tribe 5, Kubuntu and Ubuntu.

Monitor = 19" Viewsonic G90f+
GPU = ATI x1950 PRO
MB = Gigabyte GA-M55PLUS-S3G
RAM = 2GB (2x1GB)
CPU = AMD 64 X2 3800+

Kubuntu 64bit
gutsy-desktop-amd64.iso
* default screen resolution 1920 x 1440 61Hz (unable to move from this)
* could not change this (changing settings did not work)

Ubuntu 64bit
gutsy-desktop-amd64.iso
* default screen resolution 1920 x 1440 61Hz
* settings changed immediately however the reported screen resolutions seemed to be off. For example, the ideal XP Pro setting is 1152x864. To make Ubuntu look similar, I needed to set it to 1600x1200.

If you need me to test something specifically just let me know.

Revision history for this message
Alacrityathome (alacrityathome) wrote :

Just tested tribe 5 Ubuntu and hoped the new GUI for screen resolution would finally assist in recognizing my 1028 x 768 LCD intel 810/815 screen resolution.

Did not work. Only worked at low resolution on the safe video mode start up. Then use the terminal and the sudo dpkg-reconfigure xserver-xorg -phigh process as well as plugging in the horzsync and vert refresh numbers in xorg.conf. Only then do I get the 1028x768 resolution.

Is there any way for the new GUI screen resolution in Tribe 5 to accept a custom configuration? If I use the GUI to plug in the intel 810, I still can not get the GUI to pick up a custom sync level. So, by custom I would like to see the GUI be able to take a custom sync level.

Last Ubuntu that recognized my laptop resolution out of the box was 6.10.

<email address hidden>

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Just a heads up, Bryce has a discussion thread about this here:

http://ubuntuforums.org/showthread.php?t=490982

On page 11, at post 105, Bryce talks about some of his work, very interesting. He posted it yesterday.

http://ubuntuforums.org/showpost.php?p=3248403&postcount=105

Revision history for this message
Bryce Harrington (bryce) wrote :

Let's also start a spec for a true fix for this: https://wiki.ubuntu.com/X/AutodetectMonitorFrequency

DisplayConfigGtk and BulletproofX are both important, yet they are just workarounds to the true underlying problems I've outlined in the above link.

Please join with me in drafting up a much better, more powerful solution to this monitor detection mess. Contribute your thoughts, ideas, and questions in the wiki page above, to help us conceptualize a real fix to the problem for Ubuntu (and hopefully Debian too).

Revision history for this message
Alacrityathome (alacrityathome) wrote :

Many thanks, Bryce, for investing so much in this solution. I love testing a wide range of Linux live CDs and find that a % recognize my i810 1024/768 laptop monitor and a % do not recognize it. My question is not part of the wiki spec discussion but more general. Can I ask if, in your mind, there is a Linux distribution out there that has solved this challenge to your satisfaction? If so, is it possible to borrow their solution for the famous Ubuntu distribution? Sorry if this question is too noobish.....

For me, I have gotten used to the xorg.conf edit process (as long as there is a safe video boot choice) but I can see for the vast number of potential users out there and the trend to Linux.....an out of the box resolution recognition is critical.

Anyway, if you need an Ubuntu tester for this bug please let me know. I would be more than glad to help.

John Locke

<email address hidden>

Revision history for this message
Alacrityathome (alacrityathome) wrote :

Byce,

Not sure if I should post this here or add to the wiki solution but I have attached the boot screen for the MEPIS solution to the Ubuntu #3731 bug. The MEPIS 6.0 Linux distro is actually based on Ubuntu packages but they added this front end capability to resolve the monitor resolution problem. Appears to be a good solution that Ubuntu could possibly consider.

John Locke

<email address hidden>

Revision history for this message
simspace (simspace) wrote :

Thanks for all the info in this post. It was very helpful.
To those with a Westinghouse LTV-32w3 LCD TV - use the following and you will see all resolutions...
        HorizSync 50-75
        VertRefresh 60-75

Revision history for this message
maikelmeyers (mr-meyers) wrote :

I don't know if this information helps, but I have to tell ;)
When I connect my beamer to my laptop with a long (5m) vga-cable, the desktop and beamer resolution is set to 800x600 and I don't get the resolution higher.
When I use a short cable (1.5m) everything works fine (1024x768).
So for now, I have to start with the short cable, and then after booting plug the long cable :D

Revision history for this message
Michal Suchanek (hramrach) wrote :

Apparently the longer cable is defective.

I do not know how long the cable can be until the roundtrip for the signal is too long for ddc to work but 5m is not that much.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Michal:
I've noticed monitor signals don't travel well in really long VGA cables and _some_ laptops seem more susceptible than others to the problem (this is under Windows to projectors). This doesn't rule out the possibility of being able to workaround the issue but once you get a cable over 2.5 metres you can start seeing some strange issues and things like signal boosters start to help...

Revision history for this message
Demosthenes (demosthenes) wrote :

GeForce 6x series and VA1912W widescreen monitor that should be 1440x900.. Stuck on 1024x768. Don't want to go mucking anything up but this is what I believe to be the relevant sections of my XConfig file - I have enabled the 'restricted' NVidia driver (restricted, it's only restrictive to be stuck with the CPU handling all graphics and not being able to use Linux as a *desktop*).

3D acceleration and desktop effects seem to be working fine.

Section "Device"
        Identifier "nVidia Corporation NV43 [GeForce 6600]"
        Driver "nvidia"
        Busid "PCI:1:0:0"
        Option "AddARGBVisuals" "True"
        Option "AddARGBGLXVisuals" "True"
        Option "NoLogo" "True"
EndSection

Section "Monitor"
        Identifier "Generic Monitor"
        Option "DPMS"
        Horizsync 28-51
        Vertrefresh 43-60
EndSection

Section "Screen"
        Identifier "Default Screen"
        Device "nVidia Corporation NV43 [GeForce 6600]"
        Monitor "Generic Monitor"
        Defaultdepth 24
        SubSection "Display"
                Depth 1
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 4
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 8
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 15
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 16
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 24
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
EndSection

Revision history for this message
Wrwrwr (wrwrwr) wrote :

Gutsy, LG Studioworks 57i is not recognized correctly resulting in 1024x768@303Hz :) mode. This fortunately falls back to 640x480@60Hz. Running displayconfig-gtk and selecting generic monitor solves the problem (this very model is not in the database).

Revision history for this message
Checkmate (nolancheck) wrote :

This is already reported: Tecra 8000 laptop video (Neomagic MagicGraphAV256 with NM2200 chipset) automatically detects as only 640x480. I can fix that by setting HorizSync and VertSync in /etc/X11/xorg.conf. Then the fonts are way too small, so I fix that by setting a workable DPI value. I think the reason it fails is that it finds "01 ILLEGAL X86 EXTENDED OPCODE" in the Video BIOS while it's trying to read EDID data (a message in /var/log/Xorg.0.log). So the opcode is "0F 01", the INVPLG instruction. I looked in the source code for the X.Org "int10" driver where this error message is printed; there is no implementation for INVPLG (it's a privileged instruction). Now if I knew how to compile my own X.Org, I would fix that. I think an acceptable solution is to simply ignore the opcode.

I suppose I should tell all this to whoever wrote the code!

Revision history for this message
Bryce Harrington (bryce) wrote :

Heya all,

I'm just surfacing to report some progress made on resolution detection for Gutsy. We've found a fix for a sub-class of this bug, for situations involving LCDs with "analog" connections (I assume this is VGA connections as opposed to DVI) where the highest (and most correct) resolution gets lost. This is bug 27667 and is due to poor logic in xresprobe/ddcprobe.sh that mixes up CRTs and LCDs. The logic is being dropped, which will fix this bug. There were also a couple other logical errors which may have caused other related monitor resolution mis-detections.

144956 also has a fix; it addresses an issue that cropped up after Tribe 5 for intel users that resulted in misdetected resolutions for some. This was caused by a patch added in Tribe 5. The patch will be dropped to fix the issue.

For others experiencing this problem, a couple tips: run ddcprobe to see if it reports a series of timings for your monitor. If it instead returns "edidfail", you're seeing bug 94994. If it returns a correct list of resolutions, but the highest one is missing, and you're using an LCD, then you're seeing bug 27667. For everyone else, stay tuned...

Revision history for this message
Demosthenes (demosthenes) wrote :

I tried sudo ddcprobe and command was not found.. Using standard Ubuntu installation with Nvidia card and Viewsonic widescreen (VA1912W) that should be 1440x900.

Any ideas?? It's the only thing left that stops me from switching from XP to Ubuntu.

Revision history for this message
Alacrityathome (alacrityathome) wrote : RE: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600when h/v freqs incorrect

Nice progress, Bryce.

Yes, for me on Tribe 5 and on safe video (otherwise, I get a blank screen),
I get edidfail for the ddcprobe command.....so, I am one of the lucky ones.

By the way, is there a new web site for bug 3731? My old bookmarks for bug
3731
have disappeared.

Thanks.

John Locke

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Bryce Harrington
Sent: Friday, September 28, 2007 1:26 AM
To: <email address hidden>
Subject: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or
800x600when h/v freqs incorrect

Heya all,

I'm just surfacing to report some progress made on resolution detection
for Gutsy. We've found a fix for a sub-class of this bug, for
situations involving LCDs with "analog" connections (I assume this is
VGA connections as opposed to DVI) where the highest (and most correct)
resolution gets lost. This is bug 27667 and is due to poor logic in
xresprobe/ddcprobe.sh that mixes up CRTs and LCDs. The logic is being
dropped, which will fix this bug. There were also a couple other
logical errors which may have caused other related monitor resolution
mis-detections.

144956 also has a fix; it addresses an issue that cropped up after Tribe
5 for intel users that resulted in misdetected resolutions for some.
This was caused by a patch added in Tribe 5. The patch will be dropped
to fix the issue.

For others experiencing this problem, a couple tips: run ddcprobe to
see if it reports a series of timings for your monitor. If it instead
returns "edidfail", you're seeing bug 94994. If it returns a correct
list of resolutions, but the highest one is missing, and you're using an
LCD, then you're seeing bug 27667. For everyone else, stay tuned...

--
Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs
incorrect
https://bugs.launchpad.net/bugs/3731
You received this bug notification because you are a direct subscriber
of the bug.

Revision history for this message
Checkmate (nolancheck) wrote :

OK. This is from the X.Org mailing list (I wrote to it):

> Julien Cristau wrote:
>
>> On Thu, Sep 20, 2007 at 20:13:15 -0700, Nolan Check wrote:
>>
>>> I own a Toshiba Tecra 8000 laptop. The display device is a NeoMagic
>>> MagicGraph256AV, which uses the NM2200 chipset. The monitor goes up to
>>> 1024x768. When I install Xubuntu Gutsy Tribe 5 (with latest updates), it
>>> fails to detect the screen resolutions properly. It maxes out at 640x480
>>> until I adjust the HorizSync and VertSync parameters in
>>> /etc/X11/xorg.conf. The reason for this seems to be that X.Org fails to
>>> call the video BIOS function to get monitor data. (See attached
>>> /var/log/Xorg.0.log)
>>>
>>> During the VBE DDC transfer, it gets "01 ILLEGAL X86 EXTENDED OPCODE".
>>> That indicates the opcode "0F 01", correct? The INVPLG instruction.
>>>
>> Looks a bit like https://bugs.freedesktop.org/show_bug.cgi?id=11842 .
>> See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404885#46
>>
>> Julien
>
> Wow, it's just a one-character change to the code! I'd really like to try
> that patch. I guess it's time for me to figure out how to compile X.Org.

Revision history for this message
Bryce Harrington (bryce) wrote :

John, so yeah if you're seeing 'edidfail', then your bug is 94994. I recommend subscribing to that one. I have some ideas on that one and am hopeful we can knock it out next week; there's been some really good successes the past couple weeks at solving some long standing resolution bugs, and I think we're on a roll. It would kick ass if we could eliminate all these major resolution issues for Gutsy!

Demosthenes, try sudo apt-get install xresprobe; that should get ddcprobe installed for you.

For those of you on this bug's mail list, the website address is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/3731

The past day I've been going through and looking at hundreds of resolution bugs. It is astounding how many of them on close look turn out to just be bug 27667 in one form or another. I think that bug fix by itself is going to go a long way towards remedying Ubuntu's reputation for poor resolution detection support. I hadn't expected we'd be able to close so many of these resolution bugs until Hardy!

description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

Checkmate: wow, that's an insidious little bug you've found! We'll want to do some testing before we commit that. Can you file a new bug requesting that patch, and assign it to me? I think if it causes no other unusual behavior we can roll out that change for Gutsy.

Revision history for this message
Checkmate (nolancheck) wrote :

Bryce: I have submitted bug 146643.

Revision history for this message
Demosthenes (demosthenes) wrote :

thanks Bryce.. I finally found the timings for the Viewsonic VA1912W and manually created a 1440x900 resolution and enabled it and it works, and enabled anti-aliasing, vibrance, etc with the Nvidia control panel - but now another weird problem when some apps close (like a full screen app just now) keyboard and mouse lose focus to the X screen as a whole - i.e. - can't interact with the computer although mouse cursor can be moved around (but has no effect)... ideas?

I really hope the next version of Ubuntu will fix some of these bugs - it's taken a decade of solid development to get Linux to a point where it is *almost* usable for the average user, but not quite. Most people would not have a clue about manually setting timings and all these commands. But I am happy I've made some progress. Still leaves Linux in the 'need a lot of technical knowledge' category though, not quite there yet until these things are easier to resolve or better documented. Definately an improvement from when I last used Linux a few years ago though (before Ubuntu existed).

Can't say I have heard Vista is all round easy to install and maintain either though I have to admit.

Now if I can just resolve this weird 'lose focus' bug?

Would also like to know how to pipe full screen video to the TV as XP does so flawlessly.

Revision history for this message
Caroline Ford (secretlondon) wrote :

ddc probe finds the resolutions for my monitor, but not for my graphics chip?

 sudo ddcprobe
Password:
vbe: VESA 3.0 detected.
oem: NVIDIA
vendor: NVIDIA Corporation
product: CR17 Board Chip Rev A3
memory: 32768kb
mode: 640x400x256
mode: 640x480x256
mode: 800x600x16
mode: 800x600x256
mode: 320x200x64k
mode: 320x200x16m
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
edid:
edid: 1 3
id: a001
eisa: DELa001
serial: 38315a42
manufacture: 11 2002
input: sync on green, analog signal.
screensize: 31 23
gamma: 2.900000
dpms: RGB, active off, suspend, standby
timing: 640x480@60 Hz (VGA)
timing: 640x480@75 Hz (VESA)
timing: 800x600@60 Hz (VESA)
timing: 800x600@75 Hz (VESA)
timing: 1024x768@75 Hz (VESA)
ctiming: 640x480@85
ctiming: 800x600@85
ctiming: 1024x768@85
ctiming: 1280x1024@60
dtiming: 1024x768@93
monitorserial: 23DDC23B81ZB
monitorname: DELL E771a
monitorrange: 30-70, 50-160

It's an onboard nvidia gforce chip (think mx4) and an old dell crt. I am now running at 1024x768 but only by manually adding the monitor ranges to xorg.conf

Revision history for this message
Eric S. Raymond (esr-thyrsus) wrote : Virtual size default can be a problem

I've seen misbehavior similar to this bug that turned out to have a cause not listed here.

If you have a monitor capable of 20048x1536 resolution, X 7.3 will ignore the high-res modelines it gets from EDID complaining that the vertical size of the mode is too large for the virtual desktop size. This problem is due to a poor choice of default virtual-desktop size and can be fixes with an explicit Virtual declaration; I use "Virtual 2048 1536".

Revision history for this message
Bryce Harrington (bryce) wrote :

Demosthenes, please report the focus issue to a separate bug; it's almost assuredly unrelated to this one.

Caroline, interesting, it seems your card is mis-reporting its capabilities via ddcprobe. I've not run across this situation before. Are you also able to successfully specify 1280x1024 in your xorg.conf successfully? It sounds like the monitor will support it (at 60Hz tho), and I would assume the card does as well.

Eric, that's a good point about virtual desktop sizes, thanks.

Revision history for this message
aguy (astyguy-deactivatedaccount) wrote :

similar problem to Caroline

sudo ddcprobe
vbe: VESA 3.0 detected.
oem: NVidia
vendor: NVidia Corporation
product: NV17 () Board Chip Rev A2
memory: 131072kb
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 1
id: 7658
eisa: GWY7658
serial: 00001ffe
manufacture: 34 1997
input: sync on green, analog signal.
screensize: 33 24
gamma: 2.700000
dpms: RGB, active off, suspend, no standby
timing: 640x480@60 Hz (VGA)
timing: 640x480@75 Hz (VESA)
timing: 800x600@60 Hz (VESA)
timing: 800x600@75 Hz (VESA)
timing: 1024x768@75 Hz (VESA)
ctiming: 1280x1024@60
ctiming: 800x600@85
dtiming: 800x600@85
dtiming: 800x600@99
monitorname: GATEWAY CS70
monitorrange: 30-70, 50-120

I would of thought that this monitor just needs adding to bullet proof X ???

Revision history for this message
Tony Pursell (ajpursell) wrote :

Just downloaded the Gutsy Live CD and it works fine with my ATI Radeon Xpress 200 graphics and HP vs17x monitor. This was the acid test for me that the problems I originally had with the Dapper live CD install have been fixed. Awesome and well done!

Revision history for this message
minty-morky-mindy (minty-morky-mindy) wrote :

Changing Gutsy screen resolutions does not work on my computer.

Gutsy incorrectly chooses 1920x1440 at 61Hz and although I see options to change such, when I click "apply" nothing happens.

The screen resolution I need is 1152x864. I did hope that Ubuntu would finally work this time around, but no.

I now have a coaster with Ubuntu Gutsy on it.

Oh well. Maybe this will be fixed in 2008.

Revision history for this message
Caroline Ford (secretlondon) wrote : Re: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect

It is fixable - you need to edit your xorg.conf file. There will be
instructions somewhere - probably on the wiki.

> The screen resolution I need is 1152x864. I did hope that Ubuntu would
> finally work this time around, but no.
>
> I now have a coaster with Ubuntu Gutsy on it.
>
> Oh well. Maybe this will be fixed in 2008.

Revision history for this message
Demosthenes (demosthenes) wrote : RE: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect

I had a seemingly unsolveable problem with a Dell laptop screen not being recognised properly under the binary Nvidea driver that was fixed by some kind contributer uploading a EDID file to these support forums and then telling X to use that. Problem fixed. I suggest a database be created of troublesome displays and corresponding EDID files if this shows some promise to resolve some issues.

-original message-
Subject: [Bug 3731] Re: Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect
From: Chris <email address hidden>
Date: 20/10/2007 17:16

Changing Gutsy screen resolutions does not work on my computer.

Gutsy incorrectly chooses 1920x1440 at 61Hz and although I see options
to change such, when I click "apply" nothing happens.

The screen resolution I need is 1152x864. I did hope that Ubuntu would
finally work this time around, but no.

I now have a coaster with Ubuntu Gutsy on it.

Oh well. Maybe this will be fixed in 2008.

--
Xorg resolution falling back to 640x480 and/or 800x600 when h/v freqs incorrect
https://bugs.launchpad.net/bugs/3731
You received this bug notification because you are a direct subscriber
of the bug.

Revision history for this message
Checkmate (nolancheck) wrote :

May I tell you about my own issue? It's not the Tecra 8000. The Tecra 8000 issue is a pleasant problem-solving exercise compared to this:

X.Org wrongly detects the screen resolutions available on my monitor. I have an ATI Radeon X1900 XT connected to a ViewSonic VG2230wm monitor. It's a widescreen flat panel; the native resolution is 1680x1050. Ubuntu has to use the vesa driver. When I install Ubuntu or start the LiveCD environment (or do sudo dpkg-reconfigure -phigh xserver-xorg), it puts this stuff in /etc/X11/xorg.conf:

Section "Screen"
        Identifier "Default Screen"
        Device "Generic Video Card"
        Monitor "VG2230wm"
        DefaultDepth 24
        SubSection "Display"
                Modes "1680x1680" "1680x1050" "1600x1200" "1440x1440" "1400x1050" "1280x1024" "1280x960" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x640" "640x480"
        EndSubSection
EndSection

Now wait, did I just say the native resolution was 1680x1050? I sure did. So why are there mode lines like "1680x1680", "1600x1200", and "1440x1440" in here? I have no clue! But the graphical environment refuses to start up, even in "safe graphics" mode. I have to manually edit xorg.conf so that it looks like this:

Section "Screen"
        Identifier "Default Screen"
        Device "Generic Video Card"
        Monitor "VG2230wm"
        DefaultDepth 24
        SubSection "Display"
                Modes "1680x1050" "1400x1050" "1280x1024" "1280x960" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x640" "640x480"
        EndSubSection
EndSection

Then it works. It's a good thing I knew how to use Ctrl-Alt-F1 to reach a command console, use "sudo vim" to edit xorg.conf, and find the correct place in the file. A non-technical user might figure that out...if he was really, really, really desperate.
There is no bullet-proof X on Kubuntu. When I tried regular Ubuntu or Xubuntu, bullet-proof X didn't help at all. I could select a screen mode in a dialog box, but my settings seemed to have no effect.

I believe the problem is that the vesa driver goofs up parsing the monitor's EDID data. Right now, I use the radeonhd driver, built from the latest Git tree. It works perfectly fine for me. It's awesome. The attached Xorg.0.log contains all the monitor information detected by the radeonhd driver.

Unfortunately, this problem still exists in Gutsy Gibbon. I have to edit xorg.conf, even if I start the LiveCD in "safe graphics mode". Since the release of Feisty Fawn last year, I've reported this issue a few times in different places, including the Ubuntu Forums, the Ubuntu mailing lists, and the X.Org mailing list. I must say, it's like talking to a brick wall. I literally get no responses.

Doesn't anyone want to investigate? Or at least help me investigate? If you write a message telling me to shut up, I'll be happy. It means someone read my message.

Revision history for this message
Peter Clifton (pcjc2) wrote :

Checkmate, take a look at the description of this bug, and try some of the suggested things there.

sudo ddcprobe
(attach the output)

Perhaps install the "read-edid" package, and post the output from:
sudo get-edid

What is the output of:
sudo get-edid | parse-edid

Revision history for this message
Checkmate (nolancheck) wrote :

Peter, attached is the output of sudo ddcprobe.
I can't use read-edid on my 64-bit system. I extracted the EDID hex data from Xorg.0.log, compiled my own parse-edid, and fed it into there. Here's what I got:

 # EDID version 1 revision 3
Section "Monitor"
 # Block type: 2:0 3:ff
 # Block type: 2:0 3:fd
 # Block type: 2:0 3:fc
 Identifier "VG2230wm"
 VendorName "VSC"
 ModelName "VG2230wm"
 # Block type: 2:0 3:ff
 # Block type: 2:0 3:fd
 HorizSync 30-82
 VertRefresh 50-75
 # Max dot clock (video bandwidth) 170 MHz
 # Block type: 2:0 3:fc
 # DPMS capabilities: Active off:yes Suspend:no Standby:no

 Mode "1680x1050" # vfreq 59.954Hz, hfreq 65.290kHz
  DotClock 146.250000
  HTimings 1680 1784 1960 2240
  VTimings 1050 1053 1059 1089
  Flags "+HSync" "-VSync"
 EndMode
 # Block type: 2:0 3:ff
 # Block type: 2:0 3:fd
 # Block type: 2:0 3:fc
EndSection

One more detail: The monitor does seem to support 1600x1200 mode. It's pretty strange, but it shrinks the display down to 1680x1050 when I use the mode. Everything gets blurry. When you boot from LiveCD, does Ubuntu try to use the highest resolution available? I don't think that's very wise.

The modes I end up deleting from xorg.conf (1680x1680, 1440x1440) seem to fall under the category "ctiming" here. I bet the issue could be solved by making Ubuntu ignore the "ctiming" modes, because they're obviously wrong here. There are some legitimate "ctiming" modes, though. I'm gonna find whatever's calculating those modes. Maybe somewhere, there's a hidden assumption about the aspect ratio. This is a widescreen 16:10 monitor, and maybe some software can't handle that.

Thank you very, very much for responding. :)

Revision history for this message
Peter Clifton (pcjc2) wrote :

Ah, 64 bit. As I understand it, there are some issues probing monitor info on 64 bit machines that people are working on. Hopefully it will be resolved by Hardy.

People not replying probably means they don't know how to help.. that or are jealous of your huge hi-res monitor ;)

Revision history for this message
Checkmate (nolancheck) wrote :

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

Revision history for this message
Checkmate (nolancheck) wrote :

Attached is a patch for the file "ddcprobe/ddcprobe.c" in xresprobe.

Here is the REAL spec for the "aspect" field of a standard timing descriptor:
00: 16/10
01: 4/3
10: 5/4
11: 16/9

After applying this patch, it mostly works. There's no more 1680x1680 or 1440x1440 when I do "sudo dpkg-reconfigure -phigh xserver-xorg". However, I still have to edit xorg.conf and delete "1600x1200" to get X to start.

This is an extremely important patch! If anyone knows a better place to send it, please tell me!

Revision history for this message
Tony Pursell (ajpursell) wrote :

I wrote a few days ago to say that the Live CD works OK with my setup. I have now upgraded my installed version from Feisty to Gutsy and have found that the splash screen and boot progress bar does not display because the monitor complains that the settings are out of range. In Feisty the work around for this was to add a vesa code to the boot parameters in GRUB. This no longer works. Does the live CD use special boot parameters for this to work?

Revision history for this message
Tony Pursell (ajpursell) wrote :

The way I found to get the boot screen working was to install StartUp-Manager and choose a new resolution there.

Revision history for this message
nat (nathaniel42) wrote :

Well I see this what I believe to be this bug with Gutsy but not Drapper. And in Gutsy it affects all but text-mode: that is both Graphical boot screen AND X, both in the live CD + when installed. Not knowing how to override to a textmode install I had to used the live CD by pushing Ctrl+Alt+Minus until I got a 320x2?0 screen that though terribly distorted my monitor could display enough to be used. I have Gutsy installed and X working after change the H/V ranges for X's monitor, but have yet to fix and still have monitor out-of-sync issues with ubuntu's boot screen.

I know my CRT doesn't support being queried, could this be due to a lack of 'sane' defaults?

Revision history for this message
nat (nathaniel42) wrote :

Oh and safe VGA mode on the CD had the same issues!

Revision history for this message
aguy (astyguy-deactivatedaccount) wrote :

I managed to fix (via workaround) for this problem by installing gutsy and then installing "Envy".

Envy is not core ubuntu software it is written by some italian guy but the code needs to be included Ubuntu as it solves a lot of monitor configuration problems.

Revision history for this message
Checkmate (nolancheck) wrote :

I found bug 115220 recently; looks like Bryce patched the aspect ratio code on Oct. 17th.

Even with that patch, I still have to delete "1600x1200" from xorg.conf to get X to start up. And then the maximum resolution is 1400x1050 instead of 1680x1050. I'm probably seeing the issue where the monitor's highest resolution isn't available.

Revision history for this message
Bryce Harrington (bryce) wrote :

I'm dropping the priority of this from critical to high, because while there are still some important resolution problems, it appears we've solved the worst monsters. Almost every article published about Ubuntu Feisty included a mention of failure to detect resolution, but reviews of Ubuntu Gutsy now days rarely mention X resolution problems.

Changed in xorg:
importance: Critical → High
status: Confirmed → In Progress
Revision history for this message
aguy (astyguy-deactivatedaccount) wrote :

On my computer the get-edid command causes serious corruption see the strange characters at the end of this comment maybe this helps.

 sudo get-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 successful

������
�Xv�"(!�h�b�ZK�&HO�B��EY� �0X @6�
V 1X P6�
�GATEWAY CS700�2x
F�

Revision history for this message
Bryce Harrington (bryce) wrote :

blokeinlondon, the output of get-edid is binary data (thus the weird characters). You should run it like this:

 get-edid | parse-edid

Revision history for this message
aguy (astyguy-deactivatedaccount) wrote :

Thanks very much Bryce

Here is the correct info

parse-edid: parse-edid version 1.4.1
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 successful

parse-edid: EDID checksum passed.

        # EDID version 1 revision 1
Section "Monitor"
        # Block type: 2:0 3:fc
        Identifier "GATEWAY CS700"
        VendorName "GWY"
        ModelName "GATEWAY CS700"
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
        HorizSync 30-70
        VertRefresh 50-120
        # Max dot clock not given
        # DPMS capabilities: Active off:yes Suspend:yes Standby:no

        Mode "800x600" # vfreq 85.061Hz, hfreq 53.674kHz
                DotClock 56.250000
                HTimings 800 832 896 1048
                VTimings 600 601 604 631
                Flags "+HSync" "+VSync"
        EndMode
        Mode "800x600" # vfreq 75.000Hz, hfreq 46.875kHz
                DotClock 49.500000
                HTimings 800 816 896 1056
                VTimings 600 601 604 625
                Flags "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fc
        # Block type: 2:0 3:fd
EndSection

Revision history for this message
JLK (jlk) wrote :

I encounter the same bug with a fresh install of Kubuntu Hardy Alpha 3.
I have a Fujitsu laptop with i945GMA video and a 1280x800 LCD panel.

kdm appears with very big fonts, so I guess it uses a 640x480 resolution.

Attached is my Xorg.log

NB: the JHardy Alpha 3 LiveCd guessed the correct resolution. When installed,it once worked and now I have this resolution problem, without me having changed anything (not even an update/upgrade).

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Don't guess, instead attach the output of 'xranrd'. Fonts being big could be an issue with KDE at the moment.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

uh, make that 'xrandr'..

Revision history for this message
JLK (jlk) wrote :

I'm sorry. I think the resolution is correct. Only the fonts are very big when kdm launches.
Here is the result of xrandr:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 21mm
   1280x800 60.1*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right x axis y axis)

I think I'm not on the right bug ;-)

Revision history for this message
Bryce Harrington (bryce) wrote :

I think we can now close this bug as fixed as of the Gutsy release. While some resolution detection issues remain, they are uncommon and typically unrelated to the original bug report, and of course should be entered as their own bug reports.

For the 42 duplicates to this bug, I'm going to also assume our changes in Gutsy fix them. If not, please test against Hardy, and if it still isn't fixed there, undupe the bug and we'll look into it further.

Thank you everyone for testing and verifying fixes as they were developed for this bug.

Changed in xorg:
status: In Progress → Fix Released
Revision history for this message
LumpyCustard (orangelumpycustard) wrote :

Sorry to bring this up again, but I've just upgraded to Intrepid and it's doing it again.

I have a Quadro FX 500/600 nVidia card

The driver that fixes this bug was released on 7th Oct 2008 (version 177). This, however is not available from the repos yet.

This is the changelog for version 177 (from http://www.nvidia.co.uk/object/linux_display_ia32_177.80_uk.html)
Updated mode validation, in cases when no EDID is detected, such that 1024x768 @ 60Hz and 800x600 @ 60Hz are allowed, rather than just 640x480 @ 60Hz.

Was this the affecting bug?

Could we get this into Intrepid quickly?

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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