"Display out of range" after upgrade to Intrepid

Bug #290156 reported by Scott Kitterman
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Invalid
Undecided
Unassigned
X.Org X server
Invalid
High
kdebase-workspace (Ubuntu)
Invalid
High
Unassigned
Intrepid
Invalid
High
Unassigned
xorg-server (Ubuntu)
Fix Released
High
Unassigned
Intrepid
Won't Fix
High
Unassigned

Bug Description

Binary package hint: kdebase-workspace

System works fine in Hardy. Intel D945Gnt with Intel integrated graphics. Hitachi CM721F monitor gets display out of range error no matter what resolution or frequency I try. Tried dpkg-reconfigure on X. Tried xfix in the recovery console. System works fine with a Viewsonic VA903b LCD.
[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02)
     Subsystem: Intel Corporation Device [8086:544e]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ Integrated Graphics Controller [8086:2772] (rev 02)
     Subsystem: Intel Corporation Device [8086:544e]

Changed in kdebase-workspace:
importance: Undecided → High
Revision history for this message
In , Bryce Harrington (bryce) wrote :

Forwarding this bug from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+bug/290156

[Problem]
Intel D945Gnt + Hitachi CM721F monitor gets display out of range error on xserver 1.5.2.

[Discussion]
From the Xorg.0.log it appears confused what resolution to use, and ends up picking one the monitor can't do:

(II) intel(0): Using fuzzy aspect match for initial modes
(II) intel(0): Output VGA using initial mode 2048x1536

From the EDID it appears this monitor provides one modeline:

        Mode "1600x1200" # vfreq 75.000Hz, hfreq 93.750kHz
                DotClock 202.500000
                HTimings 1600 1664 1856 2160
                VTimings 1200 1201 1204 1250
                Flags "+HSync" "+VSync"
        EndMode

I'm assuming that it ought to be matching this modeline:

(II) intel(0): Modeline "1600x1200"x75.0 205.99 1600 1720 1896 2192 1200 1201 1204 1253 -hsync +vsync (94.0 kHz)

So why might it not be matching up properly? Where is the 2048x1536 resolution coming from? Is that what it's actually trying to use? Is there a way (e.g. a quirk) to force it to not use anything above 1600x1200?

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

Created attachment 19915
Parsed EDID info

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

Created attachment 19916
Xorg.0.log from failed session

Revision history for this message
Scott Kitterman (kitterman) wrote :

uname -a:
Linux kid-desktop 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux

lspci output attached.

Revision history for this message
Scott Kitterman (kitterman) wrote :

sudo discover --disable=parallel,serial,usb,ide,scsi,pcmcia --format="%M\t%S\t%D\t%i\n" video
discover: Bus not found.

sudo xresprobe intel
id: VA903 SERIES
res: 1280x1024 1280x960 1152x864 1024x768 832x624 800x600 720x400 640x480
freq: 30-82 50-85
disptype:

This is using the working LCD.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Not sure if I should blame X or krandr. More info when I have more energy for this.

Revision history for this message
Scott Kitterman (kitterman) wrote :

This is the log when using the working LCD.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Xorg.0.log.old

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

Often these issues occur due to issues with the monitor's EDID. EDID issues are monitor-specific, so that can account for why swapping monitors seems to make the issue go away.

An Xorg.0.log from booting with that monitor *should* display the EDID. Another tool for getting the EDID is available in the read-edid package. `get-edid | parse-edid`, but I'm not sure if you can run that if the monitor isn't working in the first place...

However, these sorts of EDID bugs *shouldn't* appear from a hardy->intrepid upgrade, so the fact that it did suggests that something deeper's at work. Even so, looking at the EDID may be of use.

The xrandr command line tool can also be used to add/remove modelines and examine the running X server. What I'd do is ssh into the box from another system, boot X until you get to the invalid mode situation, and poke at it with xrandr to try to get a functioning modeline. See man xrandr for documentation on this.

Perhaps with an Xorg.0.log from the failed case I can give some more specific advice, and investigate if there's any quirks, or changes in the xserver that could account for this issue.

Changed in xorg-server:
importance: Undecided → High
status: New → Incomplete
Revision history for this message
Scott Kitterman (kitterman) wrote :

Here's the log booting with the bad monitor.

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 290156] Re: "Display out of range" after upgrade to Intrepid

If the log doesn't help would running those tools in an alternate VT work?

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

(II) intel(0): Using fuzzy aspect match for initial modes
(II) intel(0): Output VGA using initial mode 2048x1536

It looks like it's not finding an exact match between your video card's resolution/refresh rates, and what your monitor can do, so it's doing a fuzzy match, which results in a resolution (2048x1536) that's out of range for the monitor. Silly thing.

For now, I think you can get around this by ssh'ing into the box and using xrandr to temporarily set a different resolution (e.g. xrandr --output VGA --mode 1024x768). That should enable you to boot up. Then use the Screen Resolution tool to select a resolution to use persistently.

If you can also attach the output of `get-edid | parse-edid` with this monitor attached, I can forward this bug upstream so we can hopefully get a permanent fix.

Changed in kdebase-workspace:
status: New → Invalid
Revision history for this message
Scott Kitterman (kitterman) wrote :

Will do when I get back to the box. Since this is a regression from Hardy,
do we need a release note or something?

Revision history for this message
Scott Kitterman (kitterman) wrote :

Output of get-edid | parse-edid.

Revision history for this message
Scott Kitterman (kitterman) wrote :

I think we're up to Triaged now.

Changed in xorg-server:
status: Incomplete → Triaged
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Scott,

I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=18276. Please subscribe to that bug, in case upstream wishes additional information or needs you to test something. Thanks ahead of time!

Revision history for this message
Scott Kitterman (kitterman) wrote :

I have a kdm specific work around. I added:

xrandr --output VGA --mode 1280x960

to

/etc/kde4/kdm/Xsetup

That particular script runs as root before the login dialogue appears so the settings affect all uses and the login dialogue. All the per user attempts were failing because the login dialogue was still at the wrong resolution. There is still a brief 'out of range' error when the initial wallpaper is shown at full resolution, but then it shifts and login/normal operation follows.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Not sure if this kind of issue should get release noted or not, but it's a regression from Hardy and a very problematic one if you happen to have the affected monitor.

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

Since this seems to be an EDID modeline mismatch, my guess is that this is a very monitor model-specific issue (i.e., other Hitachi monitors won't have this problem, just the specific model you have). It may even be particular to the specific monitor and graphics card combo (i.e., maybe swapping out either a different monitor or a different video card, and it works). So at this point I'm not sure it's important enough to put in the release notes, esp. since the workaround takes a bit to explain.

I could be wrong though - if there is a pattern of "Display out of range" regressions reported, then it could be something different in xserver's mode selection logic. Upstream should be able to clue us in on this, or if we can find a spate of bug reports similar to this one but with different monitors. If evidence proves to be the case, then yeah we definitely should include mention of it.

Regardless, I definitely agree this is well worth having a documented workaround/troubleshooting guide, even if it's not referenced in the release notes. I've written up a shot of it here:
https://wiki.ubuntu.com/X/Troubleshooting/Resolution . Please review and copyedit.

Changed in ubuntu-release-notes:
status: New → Invalid
Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
L.Lopez (ldotlopez) wrote :

I hit the same bug using LG Flatron L222WS monitor and Radeon HD 2400 PRO video card.

Adding xrandr --output VGA --mode 1650x1050 to my /etc/gdm/Init/Default doesnt work

Revision history for this message
L.Lopez (ldotlopez) wrote :

Xorg log

Bryce Harrington (bryce)
description: updated
tags: added: fuzzy-match
Revision history for this message
leshachek (vladimir-highskytech) wrote :

I have this problem trying to install Kubuntu Intrepid on a PC, Intel LGA775 with Hitachi CM715 monitor attached. I incidently was trying to install 32 bit first and had the problem. however Intrepid 64 bit version does not have this problem and I installed it smoothly within 15 minutes.
Note. Fedora 10, 64 bit seems has the same problem.
Vladimir

Bryce Harrington (bryce)
tags: added: intrepid
Revision history for this message
Scott Kitterman (kitterman) wrote :

Works fine with the same monitor on Karmic (without the work around).

Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

Changed in xorg-server (Ubuntu Intrepid):
status: Triaged → Won't Fix
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I realized I had made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Revision history for this message
In , Ajax-a (ajax-a) wrote :

The raw edid block is much more useful than the parsed one...

Revision history for this message
In , Ajax-a (ajax-a) wrote :

No EDID block means I can't work on this.

Revision history for this message
In , Sklist (sklist) wrote :

Tell me how to collect the information and I'll be glad to do it.

Revision history for this message
In , Julien Cristau (jcristau) wrote :

(In reply to comment #5)
> Tell me how to collect the information and I'll be glad to do it.

xrandr --prop should list it. Or, with kms, /sys/class/drm/card0-$output/edid.

Changed in xorg-server:
importance: Unknown → High
Revision history for this message
In , Ajax-a (ajax-a) wrote :

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

Changed in xorg-server:
status: Confirmed → Invalid
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.