Bugzilla – Bug 104640
radeon + dualhead cummulative bugreport
Last modified: 2005-10-12 11:51:06 UTC
I have a Samsung SyncMaster 920T TFT (1280x1024) that is attached to the analog output of my IBM Thinkpad T42 (Radeon 9600 Mobility). As I wanted to get a dualhead setup that combines the internal TFT (1400x1050), I fired up SaX2 using the "-r" option. SaX2 then picked the external monitor as the primary screen, but the proposed resolution was unusable - the picture was slighly flickering (like pixel noise) and the screen was too long - the bottom part was not visible. Entering the manual configuration did not reveal anything wrong - SaX2 claimed it uses the correct 1280x1024 resolution. However, it did not pick the correct monitor model ("Samsung SyncMaster 4S" was selected). As I could not find my model on the list, I inserted the driver CD and was then able to pick my monitor from there. Unfortuately the resolution was still wrong :( When testing the new configuration, the screen was still wrongly aligned. xfine claimed that it was using "1280x1024@78KHz : 73Hz", while the OSD of the monitor stated that it was driven with an unknown resolution at 49,5kHz/46Hz. Please see the config and log files attached, I hope they shed some light on this. I did not actually get to the point on trying to get a dualhead configuration working - see BUG#104597 for more info on that particular problem.
Created attachment 46015 [details] SaX.log
Created attachment 46016 [details] xorg.conf
Created attachment 46017 [details] Tarball containing the .inf files found on the vendor CD for the 920T
Hmm, the configuration file looks good to me. Matthias / Andreas do you know if we have such a Notebook here for testing ? I think this setup will come up very often so it would be nice to be able to test it at SuSE
I have a similar laptop here, ask Coolo for it.
We have a T42p, I'll fetch it for tests today anyway. I don't know exactly whether this is the same configuration, though.
I tested with T40p and it worked for me and Matthias except the MetaModes handling refering to Matthias radeon patch
Well, it certainly did not work for me. Any hints on how I can reproduce this for you so you can investigate it better? I'd like to start "from scratch", to be sure you have only the needed info.
No need to provide additional info, MetaModes parsing is appearantly corrupt. Working on that.
It is actually not the MetaModes parsing, but the SaX Screen Section / Modeline inclusion code. I've reproduced the problem, we're working on that. In the meantime you can circumvent the problem as follows: Always call 'sax -r' with the secondary monitor *detached*. Only attach after Xserver startup (if you're 'test'ing your configuration in SaX, a new Xserver is started). This seems to be a limitation of the Bios, swapping Primary and Secondary output when a monitor is attached, and you loose the internal panel information then. Enable dual view, configure the external output (monitor & maximum resolution). Last but not least select your primary monitor and just confirm it (if it is selected correctly, that is) or select your model and confirm it. This worked fine on this T42p. Some lower resolutions are not selectable in krandr yet, that is another bug. If you do *not* enable dual view, the external output can create any signal it likes to. I have seen no signal at all, perfect clone signals, broken synchronization, noisy signals, and more. And combinations of that.
*** Bug 104597 has been marked as a duplicate of this bug. ***
Ok, basically this boils down to: - bug #104728 - you have to confirm the monitor - SaX does not (yet) include some possible resolution metamodes - maybe related to some patches of bug #61858: - radeon secondary monitor output is severely broken (unsteady image), if external monitor is attached and no dualhead is configured - radeon switches primary and secondary display, somehow disabling the detection of internal panels correctly The primary / secondary monitor switching can be disabled with Option "MonitorLayout" "LVDS,AUTO" Of course, this only works for laptops.
Some additional observations: the new radeon driver module also seems to mess with the BIOS settings - after a reboot the bootup messages were suddenly displayed on the external screen instead of the Laptop display. I needed to reconfigure this in the BIOS (you can select the primary screen there), as booting from the external display causes the kernel to complain about an unknown video mode and asks me to select a VGA text mode instead (no Framebuffer on the external display?).
Behavior changes again, if the laptop is booted with external monitor attached. That the BIOS thinks the external monitor is now the primary is intentional, you couldn't have a laptop just driving an external display otherwise. However, the driver either seems to get confused about internal and external displays (fetching DDC info from different plug than BIOS panel information). And/or the backlight is no longer turned on. At least I couldn't get a display on the internal display if I booted the machine with external display plugged in, even with MonitorLayout option. I also just checked, behavior of the drivers didn't change from 9.3 to now. The old laptop profile also didn't add any MonitorLayout option for radeon. So no regression. The behavior of the drivers is - say - suboptimal, though.
(In reply to comment #12) > - maybe related to some patches of bug #61858: Wrong bugnumber, should have been bug #76860
Dualhead still doesn't work in beta3 on my laptop :-( As a workaround, I'm using radeon_drv.o from SUSE 9.3 which works.
Did you try to invoke 'sax2 -r' in runlevel 3, with the external monitor detached? If you then configure dualhead mode in sax and save it, and connect your external monitor only *after* Xserver startup, does it work or not? If not, please attach the new xorg.conf and Xorg.0.log.
Results after calling sax2 -r (with external monitor disconnected): - when the Xserver starts with the external monitor connected, the laptop display is switched off - but I can move the mouse or any window to it - when I start the Xserver with the external monitor disconnected (and connect it later), it works This means I have to disconnect the external monitor *before every Xserver startup*. Sorry, but this is _unreasonable_. BTW: It worked in 9.3 without disconnecting the external monitor - what about taking back the changes done for 10.0? ;-)
Created attachment 48266 [details] xorg logs and xorg.conf (in a .tar.bz2) (system: Acer TravelMate 803, ATI Mobility Radeon 9000
(In reply to comment #18) > - when I start the Xserver with the external monitor disconnected (and > connect it later), it works > > This means I have to disconnect the external monitor *before every Xserver > startup*. Sorry, but this is _unreasonable_. But that's the current state of the driver. As I said in comment 14, the behavior of the driver is suboptimal. Our major target WRT laptops are people giving presentations, thus plugging in projectors during runtime has to work. > BTW: It worked in 9.3 without disconnecting the external monitor - what about > taking back the changes done for 10.0? ;-) Unfortunately the only changes of the drivers we are aware of are added graphics hardware. That's something we cannot take back! There is a lot of discussion going on on xorg-devel and in the bugzilla about changes WRT display detection in the radeon driver, but all patches I've seen so far typically make things even worse. So expect this to change in one of the next driver versions, but as long as you're stuck with this driver (and it worked in 9.3) you can just copy the /usr/X11R6/lib/modules/drivers/radeon_drv.o from the 9.3 Xserver to your new installation. The ABI hasn't changed. If you already got rid of your 9.3 installation, I can send you the file. Closing this as LATER, because it sort-of works, and we currently cannot do anything about the driver.
Can you please post the X.org bugzilla URL (with bug number)? BTW: I guess it's too much effort to ship a "radeon_old" driver. Or am I wrong in this point? ;-)
Just search for 'radeon', and you'll get 91 bugs. WRT dual head: xorg #3621, #2273, WRT DGA / monitor detection: xorg #2176, #3015, #1559 WRT FN+F7 switching: xorg #2000 Special issues: xorg #2069, #2674, #2074, #2157 Yes, you are right, it is much too much overhead shipping a seperate driver.
I have tried this as suggested (keeping the external monitor disconnected until the X Server has started up) and this indeed works. I am seeing the same issues that were reported in Comment #18 (internal display stays black, when the monitor is connected during X server startup). I must agree that it is a bit suboptimal to always having to disconnect the monitor when starting up X - I hope the VGA connector on my Laptop will survive this until the radeon driver is fixed :(
Let's hope this is fixed upstream soon. We don't have register documents here right now :-( You can just copy the /usr/X11R6/lib/modules/drivers/radeon_drv.o from the 9.3 Xserver to your new installation. If SuSE Linux 9.3 worked on your machine, this should do it. If you don't have a 9.3 installation, I can send you the file.
I finally had the time to look at the xorg bugs you mentioned (thanks for the bug numbers!). It seems nobody has added a comment that the external monitor must be disconnected at startup now - I'll do so at https://bugs.freedesktop.org/show_bug.cgi?id=1559
The current CVS driver from bug #115283 has several issues fixed. You can download it in compressed form from: https://bugzilla.novell.com/attachment.cgi?id=49796 Please test this driver (replace the one in /usr/X11R6/lib/modules/drivers/ after backing it up). It certainly fixed this issue for me. Please test and report your outcome.
Tested that driver module and can confirm that it's an improvement! It now starts up in dualhead mode, even if the second display is attached, the internal display does no longer turn black. Great! Thanks a lot. I hope it's not too late to make it into the final release.
It's definitvely not on the final release, because this driver is based on CVS code, which probably will break other use cases. Especially as I heard of several complains WRT CVS code and X600 cards. SUSE Releases are always based on X.org releases, with several patches added. It seems that we're missing one of the latest additions WRT monitor detection. I don't think that we will identify this in time, and even if we did, it would not make it into the distribution. X.org 7.0 will fix the problem. For SUSE 10.0 I'll create a Wiki entry with this driver attached for download. Christian, this should work for you as well, please check.
> The current CVS driver from bug #115283 has several > issues fixed. Please test this driver. Unfortunately, it makes things even worse. The "good" news: when I start X with external monitor _disconnected_, it works - so this did not change (and is still annoying). The bad news: when I start X with the external monitor _connected_, - the laptop display is still swithed off (backlight also off) - additionally, when switching to tty1 (Ctrl-Alt-F1), the laptop display stays black (but backlight is swithed on). This is a regression compared to the driver from beta3 :-( Typing "rcxdm restart" blindly after disconnecting the external monitor brings the tty back. Note: I'm still using beta3.
This is too bad :-( Beta3 shouldn't have any differences to release WRT this. Setting to minor, because it works with attaching monitor after Xserver startup. For radeon display detection there exists a patch collection ('radeon superpatch') which I'll compile tomorrow and attach for testing. BTW - wiki entry is now http://www.opensuse.org/Laptops_and_external_VGA
Tried the radeon superpatch. Unfortenately, it crashed hard (no ping) all systems I tested it on, so I cannot really suggest trying it. If we get better relations with ATI, we can try to debug these issues in the mid-term future. But without having a reproduction of the bug in house, this is almost impossible as well. Christian, if the 9.3 driver works for you, continue to use it. The ABI hasn't changed, so it should be running stable. There are too many changes compared to current CVS code, no chance to identify monitor setup changes w/o register documentation. Closing this as FIXED, as the original reporter has his problem fixed. Christian, please reopen if in the upcoming 6.9 or 7.0 Xorg release (which Stefan will package for 10.0 as well as soon as it is ready) the problem persists.