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/
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.
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.