Bug 3621 - radeon output handling re-work
radeon output handling re-work
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
git
x86 (IA32) Linux (All)
: high normal
Assigned To: Xorg Project Team
Xorg Project Team
http://www.botchco.com/alex/xorg/supe...
:
: 2273 4936 6885 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-25 02:04 UTC by Alex Deucher
Modified: 2007-10-16 22:58 UTC (History)
24 users (show)

See Also:


Attachments
Xorg log file (48.69 KB, text/plain)
2005-08-18 11:46 UTC, Christoph Bauer
no flags Details
Xorg log file (32.07 KB, text/plain)
2005-08-21 08:10 UTC, Henrik Lilljebjörn
no flags Details
Setdvi (27.37 KB, application/x-compressed-tar)
2005-10-05 02:31 UTC, Erik Slagter
no flags Details
Xorg log with MergedFB (61.32 KB, text/plain)
2006-06-13 16:37 UTC, Manish Singh
no flags Details
Ubuntu Dapper driver package rebuilt with Alex's changes (308.02 KB, application/octet-stream)
2006-08-31 22:37 UTC, Ramesh Dharan
no flags Details
Xorg config file using MergedFB to drive external 1600x1200, clone mode (3.39 KB, text/plain)
2006-08-31 22:40 UTC, Ramesh Dharan
no flags Details
Patch against Ubuntu dapper ATI driver sources (300.87 KB, patch)
2006-08-31 22:54 UTC, Ramesh Dharan
no flags Details | Splinter Review
Xorg log using custom build for Ubuntu dapper (344.85 KB, text/x-log)
2006-09-01 10:31 UTC, Ramesh Dharan
no flags Details
patch (143.83 KB, patch)
2006-09-11 21:02 UTC, Alex Deucher
no flags Details | Splinter Review
radeon_display.c (80.53 KB, patch)
2006-09-11 21:06 UTC, Alex Deucher
no flags Details | Splinter Review
Xorg log using custom build for Ubuntu edgy (60.53 KB, text/x-log)
2006-09-28 18:13 UTC, Ramesh Dharan
no flags Details
Xorg config file using MergedFB (no longer works) (2.94 KB, application/octet-stream)
2006-09-28 18:13 UTC, Ramesh Dharan
no flags Details
Full register dump from git HEAD driver, non-working MergedFB Clone (13.43 KB, text/plain)
2006-09-30 17:48 UTC, Ramesh Dharan
no flags Details
Full register dump from hacked Dapper driver,working MergedFB Clone (13.43 KB, text/plain)
2006-09-30 17:48 UTC, Ramesh Dharan
no flags Details
xorg.conf, Xorg log, radeontool output for the above 3 cases (240.00 KB, application/x-gzip)
2006-10-13 19:18 UTC, Manish Singh
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Deucher 2005-06-25 02:04:01 UTC
This is a big collection of all the fixing I've been working on over the last
few weeks.  It's a big patch, but I can break it up when it's ready for cvs. 
It's partly based on an old patch from Hui Yu as well as some tv-out sample code
from ati.

New features:
- output mapping.  either crtc can drive any output.  An option, reversedisplay,
lets you swap the crtc maps.  Works well
- tv-out.  I haven't done extensive testing, since I don't have a tv near my pc.
pluging it into my tv-card results in an out of sync signal.  needs testing and
fixing.  also tv auto-detect is not yet implemented as I don't know how to do it.
- LVDS + internal TMDS.  if you have a laptop or docking station with LVDS and a
DVI port, set your monitorlayout to "LVDS, TMDS" and it should work, however, I
don't have such a laptop/docking station to test with, so it may need some small
tweaks yet.  Please test and let me know how it goes.
- fix tiling on r3/4xx.  tiled framebuffer now works perfectly on r3/4xx hardware
- fix dynamicclocks code.  several OUTREGs should have been OUTPLLs
- fix corruption on high res modes on on r3/4xx.  if displaypriority is set to
HIGH, bump up the display priority in the memory controller.  according to the
databooks, this is the proper behavior for hi-res displays the controller can't
handle with the default priority.

The patch is pretty invasive so there is a possibility that I've broken old
functionality or lost certain fixes.  I've tried to be careful, but it could
definitely use some more testing.

Similar to Hui's old patch, I've moved much of the display code to a new
radeon_display.c.  I've also added radeon_tvout.c and radeon_tvout.h to support
tv-out.  Add the new files and apply the patch.

The latest and greatest is available here:
http://www.botchco.com/alex/xorg/superpatch/
Comment 1 Alex Deucher 2005-06-25 02:04:51 UTC
Created attachment 2952 [details] [review]
patch
Comment 2 Alex Deucher 2005-06-25 02:07:29 UTC
Created attachment 2953 [details] [review]
patch

ignore the previous version
Comment 3 Alex Deucher 2005-06-25 02:08:04 UTC
Created attachment 2954 [details]
pixels-off.c
Comment 4 Alex Deucher 2005-06-25 02:08:25 UTC
Created attachment 2955 [details] [review]
make-xv-configable.patch
Comment 5 Alex Deucher 2005-06-25 02:09:09 UTC
Created attachment 2956 [details]
SSH pubkey
Comment 6 Alex Deucher 2005-06-25 14:13:27 UTC
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.
Comment 7 Alex Deucher 2005-06-28 06:57:16 UTC
for LVDS + TMDS testers, please try the updated patch and files here:
http://www.botchco.com/alex/xorg/superpatch/
Comment 8 Alex Deucher 2005-06-30 21:36:11 UTC
Created attachment 3007 [details]
C version of your  Pango test case
Comment 9 Alex Deucher 2005-06-30 21:37:14 UTC
Created attachment 3008 [details]
A standalone reproducing app
Comment 10 Johannes Hessellund 2005-07-25 07:24:40 UTC
Could you please make a single patch file to fix:
- fix dynamicclocks code.  several OUTREGs should have been OUTPLLs

Maybe this solves bug 2187.
Comment 11 Alex Deucher 2005-07-25 07:41:57 UTC
(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.
Comment 12 Johannes Hessellund 2005-07-25 23:15:48 UTC
(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.
Comment 13 Alex Deucher 2005-07-26 00:02:35 UTC
(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.
Comment 14 Johannes Hessellund 2005-07-26 04:05:47 UTC
(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!
Comment 15 Alex Deucher 2005-07-30 00:00:23 UTC
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.
Comment 16 David Schleef 2005-08-05 17:11:33 UTC
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.
Comment 17 Alan Coopersmith 2005-08-06 11:36:51 UTC
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.
Comment 18 Alan Coopersmith 2005-08-06 11:58:22 UTC
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.
Comment 19 Alex Deucher 2005-08-06 15:50:06 UTC
Thanks Alan! Patches integrated.  updated code here:
http://www.botchco.com/alex/xorg/superpatch/
Comment 20 Christoph Bauer 2005-08-18 11:42:23 UTC
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.
Comment 21 Christoph Bauer 2005-08-18 11:46:17 UTC
Created attachment 2917 [details]
Xorg log file
Comment 22 Henrik Lilljebjörn 2005-08-21 08:10:14 UTC
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.
Comment 23 Johannes Hessellund 2005-08-23 22:16:05 UTC
(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!
Comment 24 T. Hood 2005-09-23 05:54:58 UTC
*** Bug 2273 has been marked as a duplicate of this bug. ***
Comment 25 Erik Slagter 2005-10-05 02:22:49 UTC
(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.
Comment 26 Erik Slagter 2005-10-05 02:27:44 UTC
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").
Comment 27 Erik Slagter 2005-10-05 02:31:22 UTC
Created attachment 3488 [details]
Setdvi

The little tool as described above. It was adapted from radeontool.
Comment 28 T. Hood 2005-10-05 03:24:37 UTC
(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.
Comment 29 Erik Slagter 2005-10-05 03:29:49 UTC
(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.
Comment 30 T. Hood 2005-10-05 04:57:28 UTC
(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.
Comment 31 T. Hood 2005-10-05 04:59:46 UTC
(In reply to comment #26)
> MonitorLayout should be set as usual (like "LVDS,VGA").

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

Comment 32 Erik Slagter 2005-10-05 05:00:25 UTC
Please try with dual-head setup instead of mergedfb, it far more simple to test.
Comment 33 Erik Slagter 2005-10-05 05:04:13 UTC
(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.
Comment 34 T. Hood 2005-10-05 06:50:51 UTC
(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.)
Comment 35 T. Hood 2005-10-05 07:23:28 UTC
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".  :(
Comment 36 Johannes Hessellund 2005-10-19 22:09:06 UTC
Should this be a blocker for the Release? bug #1690

I would like this patch in the tree!
Comment 37 Matthias Hopf 2005-10-20 03:05:54 UTC
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.
Comment 38 Alex Deucher 2005-10-20 05:56:55 UTC
(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.
Comment 39 Alex Deucher 2005-10-31 22:04:42 UTC
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/
Comment 40 Lars Roland 2005-11-16 03:48:21 UTC
*** Bug 4936 has been marked as a duplicate of this bug. ***
Comment 41 Alex Deucher 2005-11-16 05:04:20 UTC
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.
Comment 42 Lars Roland 2006-01-13 22:31:50 UTC
(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 ?
Comment 43 Alex Deucher 2006-01-14 00:20:15 UTC
(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.
Comment 44 Alex Deucher 2006-02-22 13:54:11 UTC
new patch against modular:
http://www.botchco.com/alex/xorg/superpatch/modular/
Comment 45 Michel Dänzer 2006-03-07 03:47:03 UTC
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.
Comment 46 Alex Deucher 2006-03-07 03:54:18 UTC
(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!
Comment 47 Matthias Hopf 2006-03-07 05:02:01 UTC
(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.
Comment 48 Erik Andren 2006-04-02 01:04:26 UTC
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?
Comment 49 Alex Deucher 2006-04-02 04:48:30 UTC
(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.
Comment 50 Alex Deucher 2006-05-13 07:26:26 UTC
*** Bug 6885 has been marked as a duplicate of this bug. ***
Comment 51 Erik Andren 2006-06-01 10:17:22 UTC
Alex, you wouldn't mind posting an updated patch against current modular cvs?
Comment 52 Alex Deucher 2006-06-01 12:34:48 UTC
(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.
Comment 53 Alex Deucher 2006-06-01 16:04:42 UTC
(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/
Comment 54 Felipe Contreras 2006-06-07 23:22:21 UTC
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.
Comment 55 Alex Deucher 2006-06-08 06:39:20 UTC
(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.
Comment 56 Felipe Contreras 2006-06-08 19:37:55 UTC
(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.
Comment 57 Eric L. 2006-06-09 00:09:15 UTC
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
Comment 58 Johannes Hessellund 2006-06-09 00:38:42 UTC
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?
Comment 59 Felipe Contreras 2006-06-09 12:33:57 UTC
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.
Comment 60 Manish Singh 2006-06-13 16:36:28 UTC
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?
Comment 61 Manish Singh 2006-06-13 16:37:44 UTC
Created attachment 5900 [details]
Xorg log with MergedFB
Comment 62 Alex Deucher 2006-06-13 16:47:03 UTC
(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.

Comment 63 Manish Singh 2006-06-13 17:12:42 UTC
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?
Comment 64 Ramesh Dharan 2006-08-31 22:36:35 UTC
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?). 

Comment 65 Ramesh Dharan 2006-08-31 22:37:48 UTC
Created attachment 6775 [details]
Ubuntu Dapper driver package rebuilt with Alex's changes
Comment 66 Ramesh Dharan 2006-08-31 22:40:58 UTC
Created attachment 6776 [details]
Xorg config file using MergedFB to drive external 1600x1200, clone mode
Comment 67 Ramesh Dharan 2006-08-31 22:54:15 UTC
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).
Comment 68 Alex Deucher 2006-09-01 06:30:45 UTC
(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.  
Comment 69 Ramesh Dharan 2006-09-01 10:30:16 UTC
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
Comment 70 Ramesh Dharan 2006-09-01 10:31:21 UTC
Created attachment 6785 [details]
Xorg log using custom build for Ubuntu dapper
Comment 71 Manish Singh 2006-09-01 14:16:17 UTC
Re comment #69, I also noticed (2) as well, with rdesktop. It is easily
reproducible.
Comment 72 Alex Deucher 2006-09-01 14:24:33 UTC
(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.
Comment 73 Ramesh Dharan 2006-09-02 00:54:42 UTC
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. 
Comment 74 Ramesh Dharan 2006-09-07 19:41:49 UTC
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.
Comment 75 Alex Deucher 2006-09-08 00:42:52 UTC
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.
Comment 76 Michel Dänzer 2006-09-08 01:26:06 UTC
(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 .
Comment 77 Alex Deucher 2006-09-11 21:02:44 UTC
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)
Comment 78 Alex Deucher 2006-09-11 21:06:04 UTC
Created attachment 6919 [details] [review]
radeon_display.c
Comment 79 Alex Deucher 2006-09-11 21:30:35 UTC
With my latest patch LVDS + TMDS works, however the timing is still a little
tweaky on the TMDS port.
Comment 80 Manish Singh 2006-09-13 12:47:11 UTC
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.
Comment 81 Alex Deucher 2006-09-25 13:51:26 UTC
Dave just merged this into the ati driver in git HEAD.  please test that from
now on.
Comment 82 Felipe Contreras 2006-09-28 13:54:33 UTC
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.
Comment 83 Ramesh Dharan 2006-09-28 18:04:40 UTC
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.
Comment 84 Ramesh Dharan 2006-09-28 18:13:09 UTC
Created attachment 7179 [details]
Xorg log using custom build for Ubuntu edgy
Comment 85 Ramesh Dharan 2006-09-28 18:13:55 UTC
Created attachment 7180 [details]
Xorg config file using MergedFB (no longer works)
Comment 86 Ramesh Dharan 2006-09-28 18:14:19 UTC
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. 
Comment 87 Ramesh Dharan 2006-09-29 01:11:22 UTC
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.
Comment 88 Alex Deucher 2006-09-29 06:41:54 UTC
(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).

Comment 89 Ramesh Dharan 2006-09-29 12:37:01 UTC
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. 
Comment 90 Ramesh Dharan 2006-09-29 15:02:59 UTC
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
Comment 91 Alex Deucher 2006-09-29 15:41:13 UTC
(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
Comment 92 Ramesh Dharan 2006-09-30 17:48:00 UTC
Created attachment 7221 [details]
Full register dump from git HEAD driver, non-working MergedFB Clone
Comment 93 Ramesh Dharan 2006-09-30 17:48:39 UTC
Created attachment 7222 [details]
Full register dump from hacked Dapper driver,working MergedFB Clone
Comment 94 Ramesh Dharan 2006-09-30 17:49:37 UTC
Alex, hopefully those two new attachments have what you need. I generated both
the register dumps using 'radeontool regmatch "*". 
Comment 95 Alex Deucher 2006-10-01 14:09:18 UTC
(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.
Comment 96 Alex Deucher 2006-10-01 15:47:20 UTC
fixed in git head.
Comment 97 Ramesh Dharan 2006-10-01 23:23:19 UTC
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!
Comment 98 Manish Singh 2006-10-13 19:16:22 UTC
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.
Comment 99 Manish Singh 2006-10-13 19:18:06 UTC
Created attachment 7410 [details]
xorg.conf, Xorg log, radeontool output for the above 3 cases
Comment 100 Alex Deucher 2006-10-14 09:47:31 UTC
(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.
Comment 101 Manish Singh 2006-10-23 15:47:04 UTC
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?
Comment 102 Alex Deucher 2006-10-23 20:45:53 UTC
(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.

Comment 103 Manish Singh 2006-11-20 19:15:35 UTC
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.
Comment 104 Daniel Stone 2007-02-27 01:27:06 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 105 Dave Airlie 2007-07-26 18:34:31 UTC
We've merged all of this at this stage so I'm closing this bug.
Comment 106 Eric L. 2007-07-27 03:53:06 UTC
Sorry if I can read this information from somewhere else, but in which version can we expect this patch to be released?

Thanks, Eric
Comment 107 Alex Deucher 2007-07-27 05:47:54 UTC
(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.
Comment 108 Erik Slagter 2007-09-07 04:20:17 UTC
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.
Comment 109 Alex Deucher 2007-09-08 19:57:34 UTC
(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

Comment 110 Ramesh Dharan 2007-10-16 22:50:50 UTC
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? 

Comment 111 Alex Deucher 2007-10-16 22:58:20 UTC
(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.