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 (Ubuntu Intrepid)
Importance: Undecided => High
Status: New => Incomplete
--
"Display out of range" after upgrade to Intrepid
https://bugs.launchpad.net/bugs/290156
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
