Forwarding this bug from a Ubuntu reporter: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/304588 [Problem] When starting up X, nothing is displayed to the screen in Intrepid (-ati 6.8.0, xserver 1.5.2); with Hardy (-ati 6.9.0; xserver 1.4.0.90) it had been working properly. [Discussion] Comparing the Xorg.0.log's from Hardy and Intrepid, there are some slight differences in how the modelines are generated, and also a message about "Indeterminate output size" but nothing screaming out "error". This difference does look curious, but I'm not sure what it means: (II) RADEON(0): Port1: Monitor -- AUTO Connector -- VGA - DAC Type -- Primary + DAC Type -- TVDAC/ExtDAC TMDS Type -- None DDC Type -- 0x6c [lspci] 01:03.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02) Subsystem: Hewlett-Packard Company Device [103c:31fb] [Original Report] When attempting an install of Intrepid Ibex (8.10) using the amd64 desktop install CD on an HP dl380g5, the installer goes through the ping-pong stage, then the progress bar loads completely, then nothing is displayed. I've gone back and tried the Hardy Heron (8.04.1) amd64 desktop install CD and it works fine, so this is a regression. I'll be attaching the Xorg.0.log files from both intrepid and hardy to this bug. Also, I can boot the Intrepid installer using the safe graphics mode and that works for an install.
Created attachment 21787 [details] [review] Xorg.0.log from hardy (boots successfully)
Created attachment 21788 [details] [review] Xorg.0.log from intrepid (fails boot)
Created attachment 21790 [details] [review] patch for hp please try this patch. maybe you should apply it according to your local code base.
This is an xserver bug. In the case of the es1000 there is one crtc, however, two outputs are connected, and in theory both can be driven with the same crtc. However, in some cases no crtc gets assigned to one of the outputs even though both monitors have at least one common mode. Since there is no crtc, the driver call to enable to second output never happens. Anyway I think the proper fix is to figure out why the xserver fails to assign a crtc to the second output (in xf86PickCrtcs() and xf86InitialConfiguration() in xf86Crtc.c). Unfortunately, I can't seem to reproduce this at the moment on any xserver (I did last time I looked into this, but now it seems to work...). In the log, you should see: restore common restore crtc1 restore pll1 finished PLL1 restore dac restore dac "restore dac" should appear twice, once for each dac. It worked previously since the driver used to ignore the tvdac on es1000 cards. As such it was left on from the bios since the driver didn't touch it.
Created attachment 21800 [details] [review] possible patch Actually something like this might work.
Adding myself to the CC list since I was the original reporter of this problem. I'm hoping to test the patches from Alex and cooper this week to see if they resolve this problem. Thanks, Bryan
(In reply to comment #5) > Created an attachment (id=21800) [details] > possible patch > > Actually something like this might work. I tested this on the installed system and it fixes the problem. Thanks! Bryan
We've uploaded this patch to Ubuntu for Jaunty. Hopefully this will be included in 6.12?
pushed b1fd883b59b85fed8782e035890098908902f4ce
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.