Ubuntu Wiki

Over the years, Xorg has gotten much better at automatically detecting and configuring monitor resolutions. Even so, it can still get it wrong from time to time, for various reasons.

For help on manually configuring screen resolutions, please see X/Config/Resolution. For procedures to troubleshoot resolution problems, read on.

How It Works

Computer monitors contain a small binary packet of information called Extended Display Information Data (EDID), which describes the monitor's size, modelines, etc. During startup or when a monitor is hotplugged, the X server queries this data from the monitor and uses it to set a resolution.

Due to variances in how the EDID standard is implemented by different hardware manufacturers, it cannot always be 100% trusted. For instance, it may misreport things or omit capabilities (like VESA modes). The X server includes mechanisms, called 'quirks', for working around these problems and fill in missing data where appropriate.

In Karmic for Intel Graphics and Lucid for ATI and NVIDIA, the logic for setting up monitor resolutions moved from the X server to the kernel, however in some cases the quirks or other specialized logic in the X server has not been copied over.

Problem: Incorrect Resolution when no EDID available such as from old monitor or a KVM device

Sometimes the EDID from the monitor simply cannot be reached, either because it isn't there (such as in the case of some really old monitors) or some intermediary device like a KVM switcher is corrupting it or filtering it out.

If you are not using Kernel Mode-Setting, you can work around this by crafting a suitable xorg.conf. You will at least need to specify the horizontal refresh and vertical sync values, and probably also itemize the resolutions. In a worst-case situation you may need to construct modelines as well.

With KMS in use, you cannot workaround the problem using xorg.conf quite so easily. If you're lucky you can override the VGA settings by passing an appropriate kernel parameter, e.g.:

video=VGA1:1024x768

Problem: Monitor shows "Out of Range"

This typically happens when the graphics card is trying to use a resolution (and refresh rate) beyond what the monitor is capable of handling.

First, look and see if a resolution is hardcoded in your xorg.conf. These days this is rarely needed, but if you're using an xorg.conf from an older install or something, it could be set. Try moving aside your xorg.conf and boot without any xorg.conf so it's all auto-detected, or disable the resolution lines.

If booting with an auto-detected configuration doesn't work, then there is a deeper problem. Usually this indicates that the EDID information your monitor is providing is incorrect.

Workaround (for GNOME):

• Start up Ubuntu in Recovery Mode and get a root prompt

• Set GNOME to auto-login, by editing /etc/gdm/gdm.conf and setting AutomaticLoginEnable=true and AutomaticLogin to your preferred user account.

• In your ~/.xprofile add a line to specify a safer resolution:

  # Depending on your video card, your output may be 
  # 'VGA-0', 'VGA0', 'DVI', 'LVDS', etc. instead of 'VGA'
  xrandr --output VGA --mode 1024x768

• You should be able to use System > Preferences > Screen Resolution to fine tune your resolution from here, or see Configuring Resolution for ways to configure resolutions manually.

Workaround (for KDE):

• Start up Ubuntu in Recovery Mode and get a root prompt
• Hardcode the startup resolution in /etc/kde4/kdm/Xsetup (Change VGA to the proper name of your output, like DVI-1, LVDS, or whatever):

  xrandr --output VGA --mode 1024x768

• Modify the mode 1024x768 to your preferred resolution in the above line

There may still be a brief 'out of range' error when the initial wallpaper is shown at full resolution, but then it shifts and login/normal operation follows.

Workaround (for XFCE)

• Please fill this in

Troubleshooting Approach:

• Review the Xorg.0.log to see how it interprets the EDID information and what resolution it arrived at. Often errors or warnings will indicate where it has gotten confused. For example, "Using fuzzy aspect match for initial modes" indicates it did not find a valid resolution and is extrapolating (evidently incorrectly).

The output from get-edid | parse-edid (from the read-edid package) can be used to examine the EDID more closely.

Refresh rates:

• Sometimes several refresh frequencies are available for the same resolution, and choosing one over another might help. A workaround is to adjust (restrict) the h/v sync ranges in the Monitor section, see below.

Problem: The LCD's maximum resolution is detected automatically, but lower resolutions are not available

In Hardy, some bugs would prevent your monitor's EDID from being read correctly, and so X would default to a range of generic resolutions. In Intrepid, this bug was fixed, and X could correctly gather the resolutions your monitor advertises. Ironically, this "correct" behavior can result in fewer resolution options available to you, if your monitor advertises a smaller set of resolutions than the old generic defaults. In Jaunty, some better heuristics were added which provide additional resolutions even if your monitor isn't advertising them, but in Intrepid you'll need to add them manually by Creating a modeline and then adding it via xrandr. For example, to add 1280x800, you might do something like:

xrandr --newmode "1280x800" <your-modeline-here> &
xrandr --addmode LVDS 1280x800 &
xrandr --output LVDS --mode 1280x800

You can add these commands to your ~/.xprofile or your global gdm startup scripts so that they take effect on login.

Problem: Autodetection results in reduced resolutions available

X will boot up fine, but will come up with an invalid resolution. For instance, it may only provide resolutions 640x480 and 800x600. Both your monitor and card support combinations of resolutions much higher than that though.

Typically, this is caused by incorrect HorizSync and VertRefresh values. If you have either of these in your xorg.conf, try disabling them. If none are specified, then the next likelihood is that the default values being picked for your monitor are incorrect. You can check this by looking in your Xorg.0.log for something such as:

(II) Module "ddc" already built-in
(II) R128(0): VESA VBE DDC supported
(II) R128(0): VESA VBE DDC Level none
(II) R128(0): VESA VBE DDC transfer in appr. 2 sec.
(II) R128(0): VESA VBE DDC read failed
(==) R128(0): Using gamma correction (1.0, 1.0, 1.0)
(II) R128(0): Configured Monitor: Using default hsync range of 31.50-37.90 kHz
(II) R128(0): Configured Monitor: Using default vrefresh range of 50.00-70.00 Hz
(WW) R128(0): Unable to estimate virtual size

This indicates the system attempted to use DDC probing of the monitor but it failed, so it is using some generic defaults for hsync and vrefresh that are likely incorrect.

One thing to try is the NoDDC setting to shut off DDC probing:

Section "Device"
   ...
   Option "NoDDC" "true"
EndSection

A different approach is to override the h/v rates manually:

Section "Monitor"
        Identifier   "Monitor1"
        HorizSync    28.0 - 80.0
        VertRefresh  48.0 - 75.0
EndSection

Invalid EDID can also cause incorrect resolutions to be used. You can ignore the detected EDID information like this:

Section "Device"
   ...
   Option "IgnoreEDID" "true"
EndSection

If you turn off both DDC and EDID, you'll need to manually configure xorg.conf.

Problem: Wrong resolutions, refresh rates, or monitor specs

These sorts of issues used to be quite common in Feisty and earlier versions of Ubuntu, but should be quite rare these days. However, they do happen from time to time. They come in two sub-classes: Autodetection at installation, and available resolution options in tools.

In the first case, where X has successfully booted, but did so at an unexpected resolution (either too high, too low, the wrong aspect ratio, wrong refresh rate, etc.) the issue is likely an autodetection failure in xorg-server or in your video driver. Typically this only happens for hardware that is very new, very old, or very obscure; mainstream stuff ought to always get autodetected correctly.

In the second case, you may expect a range of different resolutions to be listed in the Screen Resolution tool, yet you only see a subset (or some other different set). Or potentially you might see a completely incorrect monitor shown. In these cases, the problem is likely to be that your monitor's EDID information was not correctly detected by the code in gnome-desktop (which is called from gnome-control-center and gnome-settings-daemon).

In either case, the troubleshooting process is similar.

1. Run xrandr and compare it's output with what you expected.

A common thing to check is if the TV Out output is enabled - this has been a problem especially on Intel hardware using the -intel driver; for this particular bug, the solution is to add a tv-out quirk to xserver-xorg-video-intel: Simply file a bug with the xrandr output and your chipset subsystem pci id (just include your Xorg.0.log and/or lspci -vvnn and we can get the pci id from that).

If xrandr shows the right resolutions, but the Screen Resolution tool isn't presenting that exact list to you, then that tool has a bug. File a bug including both the xrandr output and a screenshot of what Screen Resolution is offering (and of course always include your Xorg.0.log when reporting X bugs.) Meanwhile, you can use the xrandr command line tool to set your resolution.

If xrandr shows the right resolutions, but X just didn't pick the preferred one, there is probably some secondary thing going on. For instance, you may have stray gconf or .gnome2/monitors.xml settings - which you can check by logging in as a different user and seeing if you get the correct resolution. Or something else in the X startup processes may be interfering. Or perhaps your monitor failed to correctly indicate the 'preferred' resolution, or it did, but something in the process ignored that; this can be the case if you're using a CRT and want to use a resolution less than the maximum that your CRT and video card can support. Carry forth to #2.

If xrandr is *not* showing the right resolutions you expect, then there is something wrong at a lower level. Proceed on to #3.

2. Review your /var/log/Xorg.0.log.

While complex, reading through this file can show a lot of the decision making process that X goes through to decide what resolutions to use. It will indicate, for instance, resolutions that can't be used due to memory limitations, resolutions it thinks are out of range, and so on.

A particular issue to watch out for is if it has mis-understood what monitor you have attached, it may start throwing out perfectly good resolutions because it thinks they're out of sync range.

Other issues can occur if the EDID information for your monitor is incorrect; sometimes this can be fixed via quirks to xorg-server; other times you'll have to manually configure. Move on to #3.

3. Run sudo ddcprobe and/or sudo get-edid|parse-edid and see if the timings match with xrandr

A particular bug to look for is the results indicate an 'EDID fail'. If this happens, you'll probably have to manually configure your monitor settings in xorg.conf. See https://bugs.launchpad.net/ubuntu/+bug/edidfail

If there is a huge discrepancy between ddcprobe or get-edid, and what's available in xrandr, then something is borked up either in xorg-server or your video driver. File a bug with all the information collected so far.

4. Test working around manually

In general, you can bypass all the autodetection madness by using the old school method of configuring your hardware. In your xorg.conf, specify the correct device driver, monitor vrefresh and hsync, resolutions, bit depths, etc. If you can get it to work yourself, then file a bug with your original and fixed xorg.confs, along with your Xorg.0.log, the exact make and model of your monitor, the output from ddcprobe and get-edid, and so on. Often the situation is that a special quirk needs to be constructed for your hardware, and we'll need to work with upstream to determine it, so all this info will help fill in details.

If you are certain you have a correct configuration, and it *still* won't work, then it is possible you may need to generate your own modeline for the hardware. This is extraordinarily rare, but it can happen for really old or obscure monitors, or for situations where there is a very bad bug in the X code. Guides for creating modelines are googleable; please note there is risk of monitor damage if you issue a bad modeline, so take care to research properly before taking this route.

Problem: Resolution with Intel graphics was correct in Intrepid or Jaunty (with no xorg.conf configuration) but is limited in Karmic

In Karmic, Intel graphics shifted from having the X server select and set up the resolution to having this logic done in the kernel. This is beneficial in that it allows your boot sequence to work will the full graphics mode rather than just a text or simple VGA mode. However, for monitors with broken EDID, even though the X server works around the breakage the quirk may not have been copied into the kernel's code.

You can test this by rebooting Karmic with the kernel parameter modeset=0 (or nomodeset=1). If the proper resolution is brought up in this case, then file a bug report like this:

• Package: linux Subject: Missing monitor quirk for [monitor name] results in reduced resolution Tags: xorg-needs-kernel-fix

  Attachments: dmesg > dmesg.txt, xrandr --verbose > xrandr.txt and sudo dmidecode > dmidecode.txt

In the bug description, identify when you first noticed the problem (e.g. worked in Jaunty, stopped working when upgraded to Karmic).

Problem: Resolution with Intel graphics was correct in Intrepid/Jaunty/Karmic (with no xorg.conf configuration) but is limited in Lucid

Lucid uses Kernel Mode-setting for the big three drivers (-intel, -ati, and -nouveau - look in your /var/log/Xorg.0.log to see which you're using). For ATI and NVIDIA in particular, this means that the X.org code for determining resolution settings is no longer being used, and instead code within the Linux kernel's drm module is used.

Since there are some differences in how the kernel does resolution detection compared with X.org, this could potentially cause regressions (in general our expectation is that the resolution detection should be *better* but logic has been generalized a bit and can cause issues with certain corner cases).

As a workaround, try disabling KMS.

For debugging, the EDID information can be found at /sys/class/drm/*/edid. This is the raw binary file from your monitor. To review it, use the parse-edid program from read-edid, or run it through hexdump.