Ubuntu

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

Reported by Evandro Pastor on 2005-10-31
468
This bug affects 20 people
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
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.

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)?

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

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

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?

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) on 2006-03-10
Changed in xorg:
assignee: daniels → nobody

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
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

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

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

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.

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

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.

Felix Delattre (delattre) wrote :
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.

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.

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) on 2007-04-14
Changed in xorg:
importance: Medium → High
status: Needs Info → Confirmed

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.

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) on 2007-04-25
description: updated
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.

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) on 2007-04-25
description: updated
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

fallenguru (pernegger) 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.

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.

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.

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

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.

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.

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

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

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

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

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

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.

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?

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.

Bhavani Shankar (bhavi) wrote :

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

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.

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.

@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.

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.

21 comments hidden view all 101 comments
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).

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!

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

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.

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.

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.

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

Checkmate (nolancheck) wrote :

Bryce: I have submitted bug 146643.

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.

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

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".

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.

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 ???

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!

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.

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.

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.

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.

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

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

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 ;)

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

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!

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?

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.

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?

nat (nathaniel42) wrote :

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

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.

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.

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

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�

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

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

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

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.

Timo Aaltonen (tjaalton) wrote :

uh, make that 'xrandr'..

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 ;-)

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

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
Displaying first 40 and last 40 comments. View all 101 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.