Bug 3621

Created attachment 2952 [details] [review]
patch

Created attachment 2953 [details] [review]
patch

ignore the previous version

Created attachment 2954 [details]
pixels-off.c

Created attachment 2955 [details] [review]
make-xv-configable.patch

Created attachment 2956 [details]
SSH pubkey

testing:
X800 (r430) - good
9550SE (rv350) - good
m6 (rv100) - palette problems with the patch.  I haven't gotten a chance to
track down why the palette is getting setup wrong.

for LVDS + TMDS testers, please try the updated patch and files here:
http://www.botchco.com/alex/xorg/superpatch/

Created attachment 3007 [details]
C version of your  Pango test case

Created attachment 3008 [details]
A standalone reproducing app

Could you please make a single patch file to fix:
- fix dynamicclocks code.  several OUTREGs should have been OUTPLLs

Maybe this solves bug 2187.

(In reply to comment #10)
> Could you please make a single patch file to fix:
> - fix dynamicclocks code.  several OUTREGs should have been OUTPLLs
> 
> Maybe this solves bug 2187.
> 

I've already broken out the small fix ups (dynamicclocks fixes, r3/4xx tiling,
r3/4xx MC fixes) and applied them to xorg cvs, so they patch is now strictly
output handling.

(In reply to comment #11)
> I've already broken out the small fix ups (dynamicclocks fixes, r3/4xx tiling,
> r3/4xx MC fixes) and applied them to xorg cvs, so they patch is now strictly
> output handling.

Very nice, do you know if it fixes bug 2187 ?

And... another suggestion.. What about rotation. A lot of LCD panels comes with
pivot functionality, it would be nice to support rotation of displays with
radeon. Right know I must use vesa driver to rotate my display.

(In reply to comment #12)
> (In reply to comment #11)
> > I've already broken out the small fix ups (dynamicclocks fixes, r3/4xx tiling,
> > r3/4xx MC fixes) and applied them to xorg cvs, so they patch is now strictly
> > output handling.
> 
> Very nice, do you know if it fixes bug 2187 ?

I'm not sure.  I've never really had any problems with dynamicclocks on my M6. 
If it helps let me know.

> 
> And... another suggestion.. What about rotation. A lot of LCD panels comes with
> pivot functionality, it would be nice to support rotation of displays with
> radeon. Right know I must use vesa driver to rotate my display.

This is getting off-topic, if you 'd like to discuss this more, please open
request for enhancement bug or bring up the topic on the xorg ML.  There is
currently no support for accelerated rotation, although non-accelerated rotation
support could be added pretty easily.

(In reply to comment #13)
> This is getting off-topic, if you 'd like to discuss this more, please open
> request for enhancement bug or bring up the topic on the xorg ML.  There is
> currently no support for accelerated rotation, although non-accelerated rotation
> support could be added pretty easily.
 
You are right. Created bug 3871. Please comment on it. Software rotation for a
beginning is ok for me!

new patch and files available here:
http://www.botchco.com/alex/xorg/superpatch/

Includes some fixes to mergedfb crtc1 mode setting and hopefully some fixes for
LVDS+intenal TMDS.  Please test.

Created attachment 3265 [details]
hr

I applied the patch to see if this helped my laptop.  With an external monitor
attached, I get the attached log file.	It claims that it can't find the
secondary display, and then outputs to only the external monitor.  IIRC, this
is the same behavior as CVS.

Other stuff seems to work OK, so nothing obvious broken on my IGP 320.

Created attachment 3274 [details]
Corrected makefile

The new functions got addded to radeon.h in the middle of #ifdef XF86DRI
section,
and I couldn't build on a non-DRI system after applying the 29-Jul version of 
the superpatch until I added this #endif/#ifdef pair to make the new prototypes

visible to non-DRI builds.

I've also got a laptop (Acer Ferrari 4000 with Radeon Mobility X700) which can't
find it's display unless you force it to use LVDS, and then it crashes.   The
superpatch doesn't seem to make any difference with it. I've put log files and 
a simple fix for the crash in bug #4001.

Thanks Alan! Patches integrated.  updated code here:
http://www.botchco.com/alex/xorg/superpatch/

my system freezes with this patch. This line is new:

(WW) RADEON(0): libxaa too old, can't accelerate TwoPoint lines

I see only a black screen. Secondary doesn't woork too.

Created attachment 2917 [details]
Xorg log file

Created attachment 2961 [details]
Xorg log file

I tried the patch (latest patch + CVS from 18th August) to see if I could get
TV-out with my 9100 IGP. When using "MonitorLayout" "STV,NONE" X couldn't start
(see attached log-file). 

Using a CRT-monitor and "MonitorLayout" "CRT,NONE" X works OK, although there
were some distortions of the image when moving the mouse, and the framebuffer
(vesafb-tng) became corrupted.

(In reply to comment #20)
> I see only a black screen. Secondary doesn't woork too.

Me too. External LCD on the DVI is detected (at least the log says), but no
signal arrives, secondary not detected. No warnings or odd messages in log!
Ctr-Alt-Backspace works to kill the server = no hang!

*** Bug 2273 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> (In reply to comment #20)
> > I see only a black screen. Secondary doesn't woork too.
> 
> Me too. External LCD on the DVI is detected (at least the log says), but no
> signal arrives, secondary not detected. No warnings or odd messages in log!
> Ctr-Alt-Backspace works to kill the server = no hang!

This has probably to do with the bug that crept into cvs some time ago, and is
probably independent of this patch.

I have located this bug and kind of have a fix for it, but I cannot make a diff
at the moment (because temporarily no adsl => no cvs). Quite recently another
bug (=regression) crept into CVS, I will hunt that one down too, when I have
internet access again.

BTW for those who can't wait to use their DVI-enabled laptop, I have a small
program that sets the relevant bits to make the DVI output clone the VGA output
(it actually connects the TMDS to CRTC2). It does not support autoprobing in any
way, so you will have to set up timings manually (or buy a monitor with dual
VGA/DVI inputs and start X with both connected). MonitorLayout should be set as
usual (like "LVDS,VGA").

Created attachment 3488 [details]
Setdvi

The little tool as described above. It was adapted from radeontool.

(In reply to comment #27)
> The little tool as described above. 

I just tried it.  After starting X in MergedFB mode with LVDS at
1400x1050 and CRT at 1280x1024 (where the latter is a monitor with
both VGA and DVI inputs, both of which are connected to the port
expander of my ThinkPad T30), I switch the monitor to DVI input.
The monitor displays a message saying that it is in power-save mode.
I run setdvi.  The monitor displays a message saying that it cannot
display this video mode.

So it seems that setdvi does switch on the DVI output.

Now I have to figure out how to adjust the timigs.  It isn't clear
to me how this should be done.

(In reply to comment #28)
> (In reply to comment #27)
> > The little tool as described above. 
> 
> I just tried it.  After starting X in MergedFB mode with LVDS at
> 1400x1050 and CRT at 1280x1024 (where the latter is a monitor with
> both VGA and DVI inputs, both of which are connected to the port
> expander of my ThinkPad T30), I switch the monitor to DVI input.
> The monitor displays a message saying that it is in power-save mode.
> I run setdvi.  The monitor displays a message saying that it cannot
> display this video mode.
> 
> So it seems that setdvi does switch on the DVI output.
> 
> Now I have to figure out how to adjust the timigs.  It isn't clear
> to me how this should be done.

Yep. I can only test with a monitor with dual (VGA/DVI) input, so X can
autodetect the modeline.

I guess the easiest alternative is to attach a VGA monitor with the same
resolution (and LCD == 60 Hz refresh) and copy the modeline.

(In reply to comment #29)
> Yep. I can only test with a monitor with dual (VGA/DVI) input, so X can
> autodetect the modeline.
> 
> I guess the easiest alternative is to attach a VGA monitor with the same
> resolution (and LCD == 60 Hz refresh) and copy the modeline.

I did the following.

Reboot into BIOS setup; select "boot with DVI output only".
Reboot into OS.  Initial console display is on DVI output.
Start X which displays on the DVI output (only) and copy the ModeLine
reported in /var/log/Xorg.0.log.

    Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028 1066

Reboot into BIOS setup; select "boot with ThinkPad LCD display only".
(I have to do this in order to run dualhead later.)  Reboot into OS.

At this point I get somewhat confused.  I have been running in MergedFB
mode without a ServerLayout section and with only one Monitor and one Screen
section (describing the LCD panel).  In order to try to change the timings
of the 1280x1024 mode on the external monitor I add a second Screen section
and a ServerLayout section referring to both of the Screen sections.  But
settings in the second Screen section do not seem to have any effect.
The modes used for the second screen are taken from the first screen
section.  Is this normal behavior in MergedFB mode?

Anyway, I add the quoted ModeLine to _both_ screen sections, start X and
run setdvi.  The monitor in VGA mode has a slightly shifted display, which
indicates that the timings were in fact changed.  However, when switched to
DVI, the monitor still says that the video mode cannot be displayed.

(In reply to comment #26)
> MonitorLayout should be set as usual (like "LVDS,VGA").

Actually "LVDS, CRT" according to radeon(4x).

Please try with dual-head setup instead of mergedfb, it far more simple to test.

(In reply to comment #31)
> (In reply to comment #26)
> > MonitorLayout should be set as usual (like "LVDS,VGA").
> 
> Actually "LVDS, CRT" according to radeon(4x).

I was awaiting this correction ;-) Thx.

(In reply to comment #32)
> Please try with dual-head setup instead of mergedfb, it far more simple to test.


I can't get dual head to work at all without MergedFB.  The external monitor
is detected in the DDC phase but simply ignored after that.

(BTW I am using Ubuntu's xserver-xorg server, not the current CVS.)

Testing is complicated by the fact that the driver does not fully initialize
the hardware.  After trying to get dual head working both with and without
Xinerama I returned to a MergedFB configuration; however, X would only use
the external panel.  After rebooting, X was able to use both panels again.
(See #3015.)

Further info:

Making use of the spreadsheet at 

   http://suif.stanford.edu/~csapuntz/rv280-linux-dvi.html

referenced in #1129 I generated a ModeLine with "reduced blanking":

   ModeLine "1280x1024"  91  1280 1328 1360 1440  1024 1027 1034 1054

and (using MergedFB again) stuck this in the first Screen section.
The result was a significantly shifted VGA display on the external
panel.  Switching the panel to DVI input and running setdvi....
Still "Cannot Be Displayed".  :(

Should this be a blocker for the Release? bug #1690

I would like this patch in the tree!

On the systems I tried this patch the machines just crashed hard (no display, no
network activity any more, not responsive to SysRq).

I wouldn't agree the patch is already in shape to be applied by default.

(In reply to comment #36)
> Should this be a blocker for the Release? bug #1690
> 
> I would like this patch in the tree!

There's no way this patch will be ready by the release.  Sorry.

I've removed the tv-out stuff from the patch to focus on cleaning up the current
crtc/output handling.  new patch and file here:
http://www.botchco.com/alex/xorg/superpatch/

the old patch with tv-out is still available here:
http://www.botchco.com/alex/xorg/superpatch/old/

*** Bug 4936 has been marked as a duplicate of this bug. ***

one of the files in the new patch includes radeon_tvout.h (left over from the
old code), remove the include line.  I'll update the patches shortly.

(In reply to comment #41)
> one of the files in the new patch includes radeon_tvout.h (left over from the
> old code), remove the include line.  I'll update the patches shortly.

Now when the 7.0 release is out, what is the status of this patch ? - is the
code in current CVS or ?

(In reply to comment #42)
> (In reply to comment #41)
> > one of the files in the new patch includes radeon_tvout.h (left over from the
> > old code), remove the include line.  I'll update the patches shortly.
> 
> Now when the 7.0 release is out, what is the status of this patch ? - is the
> code in current CVS or ?

Still a patch. the patch is still not working 100%.  there are problems with the
palette on r1/200 chips and tmds+lvds is still not working.  I haven't really
had time to mess with it lately.

new patch against modular:
http://www.botchco.com/alex/xorg/superpatch/modular/

I don't suppose this could be broken up into smaller patches? I doubt anybody
would argue against the need to clean up this code, but I'm nervous about
introducing even more regressions after the desaster that is the radeon
multihead support in 6.9/7.0...

Also, I'm wondering whether putting this in a CVS branch might facilitate
testing and/or review.

(In reply to comment #45)
> I don't suppose this could be broken up into smaller patches? I doubt anybody
> would argue against the need to clean up this code, but I'm nervous about
> introducing even more regressions after the desaster that is the radeon
> multihead support in 6.9/7.0...
> 
> Also, I'm wondering whether putting this in a CVS branch might facilitate
> testing and/or review.

I'll see what I can do once I get my radeon box switched over to modular cvs. 
If anyone wants to help, please do!

(In reply to comment #45)
> Also, I'm wondering whether putting this in a CVS branch might facilitate
> testing and/or review.

I think this is the right direction. Right now we see too many regressions with
the superpatch, so right now it is not production ready.

Whats the status of this superpatch as of today?
It's perhaps a bad idea to try to merge the whole sucker as of whole as a lot of
hard-to-trace regressions are bound to happen. 
What about implementing a strategy of slowly merging these patches into radeon
HEAD, fixing upp regressions as they come?

(In reply to comment #48)
> Whats the status of this superpatch as of today?
> It's perhaps a bad idea to try to merge the whole sucker as of whole as a lot of
> hard-to-trace regressions are bound to happen. 
> What about implementing a strategy of slowly merging these patches into radeon
> HEAD, fixing upp regressions as they come?
> 

I've finally gotten a working modular setup on my radeon box.  I'll be working
on this as I have time.  I'm not sure yet what the best way to break this up
will be as all the parts are semi-interdependant.

*** Bug 6885 has been marked as a duplicate of this bug. ***

Alex, you wouldn't mind posting an updated patch against current modular cvs?

(In reply to comment #51)
> Alex, you wouldn't mind posting an updated patch against current modular cvs?

yes.  I've got an updated working patch against cvs, but there's a problem I
haven't tracked down such that restarting the Xserver more than once or twice
results in a blank screen (the system doesn't lock, the card just gets into an
unusable state).  I'll post what I've got tonight and hopefully someone will
beat me to the fix.

(In reply to comment #52)
> (In reply to comment #51)
> > Alex, you wouldn't mind posting an updated patch against current modular cvs?
> 
> yes.  I've got an updated working patch against cvs, but there's a problem I
> haven't tracked down such that restarting the Xserver more than once or twice
> results in a blank screen (the system doesn't lock, the card just gets into an
> unusable state).  I'll post what I've got tonight and hopefully someone will
> beat me to the fix.

updated patch and file here:
http://www.botchco.com/alex/xorg/superpatch/modular/

Hi all,

I'm very interested in TVOutput but I can't help in the development, at least
not more than janitor stuff.

I have tried the latest patch (01-Jun-2006) on the latest CVS (08-Jun-2006) and
it's working fine with Radeon Mobility 7500.

Though I don't know exactly what extras I get from applying the patch since Alex
mentioned TVOutput was disabled.

So, if I can help you with anything I'll be glad to help.

(In reply to comment #54)
> Hi all,
> 
> I'm very interested in TVOutput but I can't help in the development, at least
> not more than janitor stuff.
> 

this patch doesn't address tv-out yet.

> I have tried the latest patch (01-Jun-2006) on the latest CVS (08-Jun-2006) and
> it's working fine with Radeon Mobility 7500.
> 

good to hear!  the patch works well for me too, until I restart the X server
then I get a blank display.  The machine doesn't lock up.  Does stopping and
restarting the X server work for you?

> Though I don't know exactly what extras I get from applying the patch since Alex
> mentioned TVOutput was disabled.

With this patch you can swap the crtc to output mappings using the
"ReverseDisplay" option.  It should also allow you to use LVDS and internal TMDS
at the same time, however, I don't have a notebook with a DVI port, so I can't
test that part.

> 
> So, if I can help you with anything I'll be glad to help.

If you have the bad state at X server restart problem I have, you could help
figure out why that is happening.  I'm guessing some register state is not
properly restored and reset after the initial X server start up, but I haven't
had time to track it down.

(In reply to comment #55)
> (In reply to comment #54)
> > Hi all,
> > 
> > I'm very interested in TVOutput but I can't help in the development, at least
> > not more than janitor stuff.
> > 
> 
> this patch doesn't address tv-out yet.
> 
> > I have tried the latest patch (01-Jun-2006) on the latest CVS (08-Jun-2006) and
> > it's working fine with Radeon Mobility 7500.
> > 
> 
> good to hear!  the patch works well for me too, until I restart the X server
> then I get a blank display.  The machine doesn't lock up.  Does stopping and
> restarting the X server work for you?

Yes, it works fine. I restarted the server seven times, no problems.

> > Though I don't know exactly what extras I get from applying the patch since Alex
> > mentioned TVOutput was disabled.
> 
> With this patch you can swap the crtc to output mappings using the
> "ReverseDisplay" option.  It should also allow you to use LVDS and internal TMDS
> at the same time, however, I don't have a notebook with a DVI port, so I can't
> test that part.

Well, I don't have a DVI port either, nor an external monitor at hand, so I
guess I can't do much than just use it to see if I can find any problems.

Hi,

I have a DVI output and issues with it, as described in bug #6885, and I would
be willing to test the patch, but I'd like first to get some answers:
1. will it help solve my issue?
2. what are the risks for the hardware? (we're speaking about my employer's
hardware, if it breaks, I'm in deep sh*t).
3. I would need help/instructions for applying/compiling the patch (in the mean
time, I've got version 1:7.0.20, i.e. modularized Debian/etch version)

Thanks, Eric

I also have a external DVI monitor on the laptop. And really want to use then
simultanously.

If you could provide patched driver for Ubuntu Dapper (Xorg 7.0), I am willing
to help you out.

So what are the "easy" steps to try this out?

I would say:

cvs -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/xorg login
cvs -d :pserver:anoncvs@anoncvs.freedesktop.org:/cvs/xorg co driver/xf86-video-ati/

cd driver/xf86-video-ati
autoreconf -v -install
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make DESTDIR=/opt/xorg install

Of course, you'll have to patch the code, backup your files, and make symbolink
links to /opt/xorg. That's what I did.

Grabbing latest CVS and the latest superpatch didn't work for me. I'm using the
xorg 7.0 that's in debian unstable.

* Without a MonitorLayout it didn't detect the DVI flat panel at all. With the
vga out, it does autodetect.

* With forcing MonitorLayout to "LVDS, TMDS" it does send a signal to the DVI
flat panel, which first looks like a smattering of dots, mostly white, but some
red and green, and then a few seconds later it completely goes blank.

This is with an Thinkpad T42p with a docking station. LVDS is at 1600x1200, and
I'm attempting to run the panel at 1920x1200. In clone mode DVI out works fine.

I'm attaching my Xorg.log. Is there anything else I could do to help debug this?

Created attachment 5900 [details]
Xorg log with MergedFB

(In reply to comment #60)
> Grabbing latest CVS and the latest superpatch didn't work for me. I'm using the
> xorg 7.0 that's in debian unstable.
> 
> * Without a MonitorLayout it didn't detect the DVI flat panel at all. With the
> vga out, it does autodetect.
> 
> * With forcing MonitorLayout to "LVDS, TMDS" it does send a signal to the DVI
> flat panel, which first looks like a smattering of dots, mostly white, but some
> red and green, and then a few seconds later it completely goes blank.

You'll need to force monitorlayout to "lvds,tmds" for now until we get
autodetect going with that set up.

> 
> This is with an Thinkpad T42p with a docking station. LVDS is at 1600x1200, and
> I'm attempting to run the panel at 1920x1200. In clone mode DVI out works fine.

Mergedfb clone mode or whatever sort of clone the bios sets up by default?  Also
does does it work with a smaller mode in the DVI port (like 1280x1024 or
1600x1200)?  the internal TMDS transmitter only supports clocks up to 165Mhz. 
1920x1200@60Hz would require a clock of ~210 Mhz.

BIOS clone mode. 

Neither 1600x1200 nor 1280x1024 work, similar dots on the screen, although with
lower res they look vaguely like windows.

Since 1920x1200 actually works as a single head, doesn't that mean the hardware
supprots it?

Hey, I figured some of you folks may find this useful: I managed to apply Alex's
superpatch to the current Dapper sources for the xserver-xorg-driver-ati
package. The resulting driver works and I can use Clone/MergedFB with my T42 and
docking station to drive my external 1600x1200 display. 

This is a huge improvement for me over the existing Radeon driver that ships
with Dapper; with that driver, all I managed to do was drive the external
display at 1400x1050, and only if I booted the machine while docked, and with
significant screen corruption to boot ;-).

Anyway I've attached the working radeon_drv.so, plus a copy of the package I
built. I know very little about how to use dpkg-buildpackage correctly so I
think this thing is versioned all wrong; if someone can explain to me how to
bump the version or otherwise change something so this package gets created with
a new version number I'd appreciate it. 

A couple of caveats:

- I had to do a bit of questionable hacking in radeon_driver.c to account for
differences between the Ubuntu source and the more recent Xorg source. This was
confined to DRM stuff which doesn't work for the R350 anyway, which is what I
have (i.e. the ATI Mobility Radeon 9600 M10) but it might have broken something
else. 

- The new driver appears to break compatibility with the DRM kernel module
(radeon.ko). This isn't surprising, and again was irrelevant to me, so I just
removed that module from /lib/modules to prevent it from getting loaded (is
there a better way to do this?). 

Created attachment 6775 [details]
Ubuntu Dapper driver package rebuilt with Alex's changes

Created attachment 6776 [details]
Xorg config file using MergedFB to drive external 1600x1200, clone mode

Created attachment 6777 [details] [review]
Patch against Ubuntu dapper ATI driver sources

This patch applies against the current xserver-xorg-driver-ati package in
Ubuntu dapper (v. 6.5.7.3).

(In reply to comment #64)
> Hey, I figured some of you folks may find this useful: I managed to apply Alex's
> superpatch to the current Dapper sources for the xserver-xorg-driver-ati
> package. The resulting driver works and I can use Clone/MergedFB with my T42 and
> docking station to drive my external 1600x1200 display. 

Good to hear Ramesh!  Can you also attach your Xorg log?  I actually just
purchased a laptop with a DVI port, so I'm planning to start working on this
patch again in the coming weeks.  

Ok, attaching my Xorg log. Also, I noticed that the current version of the patch
has two issues that I noticed:

(1) There are some RADEONTRACE statements in radeon_driver.c and radeon_display.c  
    that result in a lot of chattiness in the Xorg log (DoAdjustFrame, one 
    elsewhere that logs a ton of register writes, etc.). I nuked these in a 
    newer build of the driver.

(2) Palette/depth conversion handling appears semi-broken. Specifically, with   
    the current version 
    of the patch, if I run rdesktop against a remote host using 16-bit depth, 
    every time I change focus to and from the rdesktop Window, my entire screen 
    goes blank, often for several seconds, before everything goes back to 
    normal. I see log statements referring to palette manipulation but I didn't 
    really investigate this much as it's not a showstopper for me at the moment.h

Created attachment 6785 [details]
Xorg log using custom build for Ubuntu dapper

Re comment #69, I also noticed (2) as well, with rdesktop. It is easily
reproducible.

(In reply to comment #71)
> Re comment #69, I also noticed (2) as well, with rdesktop. It is easily
> reproducible.

With or without my patch or both? if it's without the patch please file a new
bug for that.

I just reverted back to the stock driver to confirm this: the palette issue does
*not* happen for me with the stock Ubuntu Xorg 7.0 driver (6.5.7.3-0ubuntu7), it
only manifests when I'm using the hacked version with your patch applied. 

Also, the palette/depth conversion issue only affects the externally connected
monitor. I'm using clone mode and the laptop display looks fine the whole time
even though the external display is freaking out.

I've re-based my patches against radeon git.  They work ok on a 9550 desktop
card, but I'm getting an XIO error n mode validation on my laptop.

(In reply to comment #75)
> I've re-based my patches against radeon git.  They work ok on a 9550 desktop
> card, but I'm getting an XIO error n mode validation on my laptop.

Could be bug 8137. Try reverting commit caaed927a07ffbac68b08246185ef93c1e7bb98c .

Created attachment 6918 [details] [review]
patch

my server is down, so I'm attaching the latest version of radeon_display.c and
my patch.  Requires commit caaed927a07ffbac68b08246185ef93c1e7bb98c (includes
the patch in bug 8137)

Created attachment 6919 [details] [review]
radeon_display.c

With my latest patch LVDS + TMDS works, however the timing is still a little
tweaky on the TMDS port.

With the new patch, I'm getting pretty much the same results as before. No
MergedFB configurations work, but I can get 1920x1200 out on a single head via
the DVI port.

Dave just merged this into the ati driver in git HEAD.  please test that from
now on.

I tested the git version (HEAD) of yesterday, and I didn't find any problems.

However, I'm still not sure exactly what I can do with it. I have an external
monitor and a TV to test. If I plug in the monitor it seems to be detected, but
I see nothing there.

Thanks for the work on this.

I just tried out the git version and I'm sad to report that functionality has
regressed for me. 

I retrieved the source using the following git command:
git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati

I then used autogen.sh and eventually got the driver to build. I loaded it and
it drives the internal panel fine, but refuses to drive my externally connected
monitor, a Dell 2001FP. It appears to be a timing issue - the monitor's status
light is green, but there's no picture. The laptop internal panel looks fine. 

I was previously using the following set of options:
DisplayPriority "BIOS", DynamicClocks "true", and MonitorLayout "LVDS, TMDS". 

I removed them all, but there was no change in behavior. I also tried booting
with the head connected, but no dice.

I'll attach the xorg.conf and logfile shortly.

Created attachment 7179 [details]
Xorg log using custom build for Ubuntu edgy

Created attachment 7180 [details]
Xorg config file using MergedFB (no longer works)

I've attached my Xorg.conf and Xorg.0.log. 

Other information that might be relevant: I'm running the current Ubuntu Edgy
Beta, with kernel 2.6.17 and the radeon and drm modules loaded. 3D appears to
work fine (at least, glxgears runs). 

Also, previously when I switched to a console VTs the console output used to be
cloned on both heads. Now when I switch, the external DVI display is powered off
(status light switches to amber) and only the internal panel head remains active. 

I enabled "BIOS clone mode" and confirmed that using the current driver from git
HEAD I can drive the external head at 1600x1200 (assuming I boot with it
connected). 

So basically I think I'm in exactly the same state as Manish. And the question
is why it worked better when I backported the patch to the older radeon driver
and Xorg server (driver 6.5.7.3, Xorg 7.0.0), i.e. what breaks it it.

(In reply to comment #87)
> I enabled "BIOS clone mode" and confirmed that using the current driver from git
> HEAD I can drive the external head at 1600x1200 (assuming I boot with it
> connected). 
> 
> So basically I think I'm in exactly the same state as Manish. And the question
> is why it worked better when I backported the patch to the older radeon driver
> and Xorg server (driver 6.5.7.3, Xorg 7.0.0), i.e. what breaks it it.

trying diffing your older patched version with the version in git and identify
what is being done differently.  You can also compare CRTC, CRTC2 and FP/TMDS,
etc. regs using radeontool
(http://ozlabs.org/~jk/docs/mergefb/radeontool-hacked.tar.gz).

Ok, here's some radeontool regs output. 

Xorg 7.1.1, git HEAD radeon driver, MergedFB "true", MonitorLayout "LVDS, TMDS",
MetaModes "1400x1050-1600x1200":

RADEON_DAC_CNTL         00000002
RADEON_DAC_CNTL2        00000020
RADEON_TV_DAC_CNTL      00000000
RADEON_DISP_OUTPUT_CNTL 00000000
RADEON_CONFIG_MEMSIZE   04000000
RADEON_AUX_SC_CNTL      00000000
RADEON_CRTC_EXT_CNTL    00008000
RADEON_CRTC_GEN_CNTL    03210600
RADEON_CRTC2_GEN_CNTL   02210680
RADEON_DEVICE_ID        00004e50
RADEON_DISP_MISC_CNTL   5b300600
RADEON_GPIO_MONID       00100000
RADEON_GPIO_MONIDB      00000000
RADEON_GPIO_CRT2_DDC    00000000
RADEON_GPIO_DVI_DDC     00100300
RADEON_GPIO_VGA_DDC     00100300
RADEON_LVDS_GEN_CNTL    003cffa1
RADEON_FP_GEN_CNTL      0003048d

I'll post the output from the old driver shortly. 

And here's the output from the hacked driver (superpatch backported to Xorg
7.0/dapper), with the same Xorg configuration:

RADEON_DAC_CNTL         ff002002
RADEON_DAC_CNTL2        00000020
RADEON_TV_DAC_CNTL      07770142
RADEON_DISP_OUTPUT_CNTL 1000000a
RADEON_CONFIG_MEMSIZE   04000000
RADEON_AUX_SC_CNTL      00000000
RADEON_CRTC_EXT_CNTL    11008001
RADEON_CRTC_GEN_CNTL    03210600
RADEON_CRTC2_GEN_CNTL   02210680
RADEON_DEVICE_ID        00004e50
RADEON_DISP_MISC_CNTL   5b300600
RADEON_GPIO_MONID       00000000
RADEON_GPIO_MONIDB      00000000
RADEON_GPIO_CRT2_DDC    00000000
RADEON_GPIO_DVI_DDC     00000300
RADEON_GPIO_VGA_DDC     00000300
RADEON_LVDS_GEN_CNTL    003cffa1
RADEON_FP_GEN_CNTL      0003048d

(In reply to comment #89)
> Ok, here's some radeontool regs output. 
> 

hmmm...none of those bits seems like it would cause a problem, but I'll do some
testing and dig into it further.  Can you give me working and non-working dumps
of the full set of display controller regs?

RADEON_CRTC_GEN_CNTL
RADEON_CRTC_EXT_CNTL
RADEON_DAC_CNTL
RADEON_CRTC_H_TOTAL_DISP
RADEON_CRTC_H_SYNC_STRT_WID
RADEON_CRTC_V_TOTAL_DISP
RADEON_CRTC_V_SYNC_STRT_WID
RADEON_FP_H_SYNC_STRT_WID
RADEON_FP_V_SYNC_STRT_WID
RADEON_FP_CRTC_H_TOTAL_DISP
RADEON_FP_CRTC_V_TOTAL_DISP
RADEON_CRTC_OFFSET
RADEON_CRTC_OFFSET_CNTL
RADEON_CRTC_PITCH
RADEON_DISP_MERGE_CNTL
RADEON_CRTC_MORE_CNTL
RADEON_CRTC2_GEN_CNTL
RADEON_DAC_CNTL2
RADEON_TV_DAC_CNTL
RADEON_DISP_OUTPUT_CNTL
RADEON_DISP_TV_OUT_CNTL
RADEON_DISP_HW_DEBUG
RADEON_CRTC2_H_TOTAL_DISP
RADEON_CRTC2_H_SYNC_STRT_WID
RADEON_CRTC2_V_TOTAL_DISP
RADEON_CRTC2_V_SYNC_STRT_WID
RADEON_FP_H2_SYNC_STRT_WID
RADEON_FP_V2_SYNC_STRT_WID
RADEON_FP_CRTC2_H_TOTAL_DISP
RADEON_FP_CRTC2_V_TOTAL_DISP
RADEON_CRTC2_OFFSET
RADEON_CRTC2_OFFSET_CNTL
RADEON_CRTC2_PITCH
RADEON_DISP2_MERGE_CNTL
RADEON_TMDS_PLL_CNTL
RADEON_TMDS_TRANSMITTER_CNTL
RADEON_FP_HORZ_STRETCH
RADEON_FP_VERT_STRETCH
RADEON_FP_GEN_CNTL
RADEON_FP2_GEN_CNTL
RADEON_LVDS_GEN_CNTL
RADEON_GRPH_BUFFER_CNTL
RADEON_GRPH2_BUFFER_CNTL
RADEON_CRTC_MORE_CNTL
DAC_EXT_CNTL
DAC_MACRO_CNTL

Created attachment 7221 [details]
Full register dump from git HEAD driver, non-working MergedFB Clone

Created attachment 7222 [details]
Full register dump from hacked Dapper driver,working MergedFB Clone

Alex, hopefully those two new attachments have what you need. I generated both
the register dumps using 'radeontool regmatch "*". 

(In reply to comment #94)
> Alex, hopefully those two new attachments have what you need. I generated both
> the register dumps using 'radeontool regmatch "*". 

Perfect!  the TMDS transmitter and PLL regs were not set up properly.  I'll be
committing a fix to git shortly.

fixed in git head.

Thanks Alex, I just synced the new source, built the driver, and Clone mode
works great. What's more, the palette issues I saw before are gone, and 3D/DRI
are working as well!

For me, with git head:

* Single head 1920x1200 via the DVI port works
* Dual head LVDS, TMDS 1600x1200-1680x1050 works
* Dual head LVDS, TMDS 1600x1200-1920x1200 does *not* work

I'll attach xorg.conf, Xorg log, and radeontool regmatch output for each case.

Created attachment 7410 [details]
xorg.conf, Xorg log, radeontool output for the above 3 cases

(In reply to comment #98)
> For me, with git head:
> 
> * Single head 1920x1200 via the DVI port works
> * Dual head LVDS, TMDS 1600x1200-1680x1050 works
> * Dual head LVDS, TMDS 1600x1200-1920x1200 does *not* work
> 
> I'll attach xorg.conf, Xorg log, and radeontool regmatch output for each case.

I suspect this may be a bandwidth problem since 1920x1200 is right on the limit
of the TMDS clock.  Combined with a large mode on LVDS (near the LVDS limit as
well) there may be bandwidth issues with the chip being able to feed both heads
with data.  You might try setting the displaypriority option to HIGH or forcing
a lower refresh rate (like 50Hz) on the TMDS mode.

DisplayPriority HIGH makes no difference, and I was unable to get the
CRT2VRefresh  option to actually take.

I tried under Windows XP, and it was able to drive 1600x1200-1920x1200 at 60Hz
just fine, so the hardware is capable of it.

Xorg.log has things like:

(WW) (1920x1200,CRT2 Monitor) mode clock 193.16MHz exceeds DDC maximum 170MHz
(II) RADEON(0): Not using default mode "960x600" (bad mode clock/interlace/doubl
escan)
(WW) (1920x1200,CRT2 Monitor) mode clock 230MHz exceeds DDC maximum 170MHz
(II) RADEON(0): Not using default mode "1920x1200" (hsync out of range)

Perhaps the code that detects the limits of the hardware is buggy?

(In reply to comment #101)

> 
> (WW) (1920x1200,CRT2 Monitor) mode clock 193.16MHz exceeds DDC maximum 170MHz
> (II) RADEON(0): Not using default mode "960x600" (bad mode clock/interlace/doubl
> escan)
> (WW) (1920x1200,CRT2 Monitor) mode clock 230MHz exceeds DDC maximum 170MHz
> (II) RADEON(0): Not using default mode "1920x1200" (hsync out of range)
> 
> Perhaps the code that detects the limits of the hardware is buggy?
> 

You probably need to use reduced blanking modes for the DVI otherwise the clock
is too high.  See bug 2859.

Yep, that did the trick! I had to add the following:

        Option          "ReducedBlanking"
        ModeLine        "1920x1200@60" 154.00 1920 1968 2000 2080  1200 1203 120
9 1235

and change the MetaModes to reference 1920x1200@60. I also had to hardcode the
monitor layout (it wouldn't detect the DVI monitor on its own)

This is with git as of today.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

We've merged all of this at this stage so I'm closing this bug.

Sorry if I can read this information from somewhere else, but in which version can we expect this patch to be released?

Thanks, Eric

(In reply to comment #106)
> Sorry if I can read this information from somewhere else, but in which version
> can we expect this patch to be released?

The soon to be released 6.7 will have these changes and then the randr branch breaks it down even nicer.

Fedora 7 ships with xorg 7.2 (which seems significantly "newer" than 6.7). Still it doesn't have your patches, for instance strings on the radeon driver doesn't give your "ReverseDisplay" option.

Please give a full step-by-step manual for compiling the newest ati driver from source (which I found to be next to impossible using the "modular" driver). Or please give a precompiled version for use with xorg 7.2, so I can test.

(In reply to comment #108)
> 
> Please give a full step-by-step manual for compiling the newest ati driver from
> source (which I found to be next to impossible using the "modular" driver). Or
> please give a precompiled version for use with xorg 7.2, so I can test.
> 

The latest radeon driver needs xserver 1.3 (which I think is already be included with fedora 7).  You may be able to find pre-packaged rpms for 6.7.192 or you can grab them from rawhide.  If you want to build the driver yourself, you'll need to install the build deps for the driver (xorg-devel, xserver-devel, mesa-devel, xorg-macros, pkg-config, m4, automake, autotools, git-core, etc.).  Once you have all those:

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
cd xf86-video-ati
./autogen.sh --prefix=/usr
make
sudo make install

I just tried out version 6.7.195(-1ubuntu2), the latest version available in the Ubuntu Gutsy RC. 

Things are better than the last time I poked around with this stuff a year ago, but *still* not nearly good enough to replace Windows for my use cases:

(1) If I boot the laptop while undocked, then dock, the largest mode I can switch to on my DVI head is 1280x1024. I'm sure this is because when the driver loaded, there was nothing plugged in to the DVI output. Perhaps I'm supposed to add a mode by hand using xrandr --newmmode? Ugh.

(2) The new displayconfig-gtk widget in Ubuntu has its own idea of my multihead configuration which is completely divorced from the driver state as far as I can tell. Using xrandr by hand, I can get the modes I want (barring the issue in (1) which is a showstopper for me), but displayconfig-gtk still shows only one active head. If I try to activate the other head by hand, I'm told to restart X, and when I do, it comes up in some weird safe mode using the VESA driver. WTF? Presumably the radeon driver is not reporting state properly back through whatever channels displayconfig-gtk uses to do its thing? Or is that app just broken? 

(In reply to comment #110)
> I just tried out version 6.7.195(-1ubuntu2), the latest version available in
> the Ubuntu Gutsy RC. 
>

Please report these as a new bug and attach your Xorg config and log.