Created attachment 25910 [details]
xort.conf (Card0 is radeonhd, Card1 is radeon)

Created attachment 25911 [details]
Camera shot with radeon

Created attachment 25912 [details]
Camera shot with radeonhd (works)

Created attachment 25913 [details]
Radeonhd's xorg.log (works)

Created attachment 25914 [details]
Radeon's xorg.log (stripes)

Created attachment 25915 [details]
Radeon's xorg.log (single, works)

Does radeon work correctly if you plug in the second monitor after you've started X and enable it with xrandr?  Also can you try git master or the 6.12-branch of xf86-video-ati?

Created attachment 25923 [details]
Fail of plug of second monitor

I tried to plug the second monitor and run `xrandr --output DVI-0 --auto`, but the screen on LVDS stopped to be updated (the stripes slowly arrived) and the second monitor didn't get the screen. I was able to switch to console with no problems. Logs attached.

I will try the git 6.12 branch in a few days.

The radeonhd is working perfectly with the hot-plugging the second monitor. If you need some detailed logs, please tell me (and which option to enable in the xorg.conf). Thanks!

It was easier than I thought. The 6.12 branch worked much better. I tried the setup with two monitors from the beginning, I had the screen on LVDS, but 1024x768 only. After I logged into the KDE 3.5.10, the xrandr was able to set 1280x800 on LVDS (`xrandr --output LVDS --auto`), but I was not able to change resolution on DVI-0: xrandr: cannot find crtc for output DVI-0

The output from `xrandr` after I run the `xrandr --output LVDS --auto` command looked like (LVDS is native 1280x800, DVI-0 is native 1280x1024):

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1400 x 1400
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.0*+
   1280x720       59.9
   1152x768       59.8
   1024x768       60.0     59.9
   800x600        60.3     59.9
   640x480        59.9     59.4
VGA-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0 +   75.0     60.0     60.0
   1400x1050      60.0
   1280x960       60.0
   1152x864       75.0     75.0
   1024x768       75.1     75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     66.7     60.0     59.9
   720x400        70.1
DVI-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0 +   75.0     60.0     60.0
   1400x1050      60.0
   1280x960       60.0
   1152x864       75.0     75.0
   1024x768       75.1     75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     72.8     75.0     66.7     60.0     59.9
   720x400        70.1

Created attachment 25924 [details]
Radeon's xorg.log - 6.12 branch

Looks like your system is one of the ones that requires proper handling of router objects.  It's detecting both DVI-0 and HDMI-0 as attached since they share a gpio for ddc.  You should be able to force HDMI off in order to change the mode on DVI:
xrandr --output HDMI-0 --off
xrandr --output DVI-0 --mode 1280x1024

Can you attach your video bios?

(as root)
cd /sys/bus/pci/devices/<pci bus id of video card>/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

Created attachment 25933 [details]
ATI's BIOS (ATI Mobility Radeon HD 3470, 256MB VRAM)

(In reply to comment #12)
> ...  You should be able to force HDMI off in order to change
> the mode on DVI:
> xrandr --output HDMI-0 --off
> xrandr --output DVI-0 --mode 1280x1024

The correct sequence is to enable the HDMI-0 again, because the DVI-0 output gets blank after the first command. Running `xrandr --output HDMI-0 --auto` after those two commands enables the output again (with the correct resolution).

Update on the master git tree: the screen works from the beginning (in 1024x768, mirror). The `xrandr` output now shows two DVI's (as a consequence to the recent commit on HDMI-B I guess):

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2560 x 1024
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.0 +
   1280x720       59.9
   1152x768       59.8
   1024x768       59.9*
   800x600        59.9
   640x480        59.4
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0 +   75.0     60.0
   1152x864       75.0
   1024x768       75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     66.7     59.9
   720x400        70.1
DVI-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0 +   75.0     60.0
   1152x864       75.0
   1024x768       75.0     70.1     60.0*
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     66.7     59.9
   720x400        70.1

I noticed this bug seems exactly the same bug (512318) which I found on bugs.redhat.com, and where I added my own notes about the problem, and eventually how to get somehow around it:
https://bugzilla.redhat.com/show_bug.cgi?id=512318

Although there it is reported as a xrandr bug, it seems to me also it is in radeon X driver.

(In reply to comment #16)
> Although there it is reported as a xrandr bug, it seems to me also it is in
> radeon X driver.

I think it is definitely something in the radeon driver, because radeonhd works fine.

Updated title as the current driver doesn't draw the stripes, but has problems with second monitor.

What connectors does your laptop actually have?  According to the bios it has HDMI, DVI, LVDS, and VGA.  The DVI and HDMI are both connected to the same physical encoder and ddc line, so they will always be mirrors.

(In reply to comment #19)
> What connectors does your laptop actually have?  According to the bios it has
> HDMI, DVI, LVDS, and VGA.  The DVI and HDMI are both connected to the same
> physical encoder and ddc line, so they will always be mirrors.

My laptop has (Acer TravelMate 5730G): LVDS, HDMI, VGA
My port replicator: DVI, VGA

It is possible that the VGA ports are the same and that the HDMI/DVI has the same signal (I cannot verify, I don't have the HDMI screen).

I have only the LVDS and DVI (from port replicator) active/connected.

The radeonhd driver reports PANEL (connected), VGA_1 (disconnected), DVI-D_1 (connected), DVI-D_2 (disconnected).

(In reply to comment #19)
> What connectors does your laptop actually have?  According to the bios it has
> HDMI, DVI, LVDS, and VGA.  The DVI and HDMI are both connected to the same
> physical encoder and ddc line, so they will always be mirrors.

Mirror is not the correct word, because I'm able to change the resolution on DVI-0 while the xrandr on HDMI-0 reports the old one.

But switching off HDMI-0 switches off my LCD screen, but `xrandr HDMI-0 --auto` doesn't switch it on again. I have to switch off DVI-0 and switch _both_ (order doesn't matter) on again (`xrandr --output XY --auto`).

Second thing is that I don't have the LVDS running now; `xrandr --output LVDS --auto` reports "xrandr: cannot find crtc for output LVDS".

Software: xorg-server 1.7.1, libdrm 2.4.15, mesa 7.6, vanilla kernel 2.6.32-rc7.

Created attachment 31205 [details]
Radeon's Xorg.0.log (radeon git master)

Updated status

Created attachment 31248 [details] [review]
deal with connectors sourced to the same encoder

Does this patch help?

Created attachment 31249 [details] [review]
Radeon's Xorg.0.log (radeon git master, bug21767.diff applied)

The system didn't get to start the graphics at all with the patch:

...
Enable CRTC 0 success
Enable CRTC memreq 0 success
Unblank CRTC 0 success
encoder already driven by other crtc

Fatal server error:
AddScreen/ScreenInit failed for driver 0

Created attachment 31250 [details] [review]
deal with connectors sourced to the same encoder v2

Can you try this one? (remove the previous patch).

Created attachment 31251 [details]
xrandr output

Created attachment 31252 [details]
Radeon's Xorg.0.log (radeon git master, bug21767-2.diff applied)

The graphics booted up into 1024x768 on LCD (that has maximum 1280x1024), but LVDS didn't come up - xrandr still reports no CRTC for LVDS and it has both HDMI-0 and DVI-0.

Created attachment 31262 [details] [review]
deal with connectors sourced to the same encoder v3

Third time's the charm hopefully...

Created attachment 31267 [details]
Radeon's Xorg.0.log (radeon git master, bug21767-3.diff applied)

X started, but the LVDS and LCD (DVI) are both black.

(In reply to comment #29)
> Created an attachment (id=31262) [details]
> deal with connectors sourced to the same encoder v3
> 
> Third time's the charm hopefully...

If I understand the patch correctly, we are now getting the DVI working (and shown only on DVI-0 output). Right?

Maybe it would be better if I have at least LVDS working, so that I can reply from X without restarting to radeonhd driver :-)

Fixing the DVI/HDMI issue will also fix LVDS.  The issue is that xrandr is treating DVI and HDMI separately even though they are driven by the same physical encoder.  Since there are only 2 crtcs, randr grabs them for DVI and HDMI which leaves nothing for LVDS.

(In reply to comment #32)
> Fixing the DVI/HDMI issue will also fix LVDS.  The issue is that xrandr is
> treating DVI and HDMI separately even though they are driven by the same
> physical encoder.  Since there are only 2 crtcs, randr grabs them for DVI and
> HDMI which leaves nothing for LVDS.

I see! Thanks for the explanation.

Created attachment 31268 [details] [review]
deal with connectors sourced to the same encoder v4

Take 4.

Created attachment 31269 [details]
Radeon's Xorg.0.log (radeon git master, bug21767-4.diff applied)

Finally I see LVDS up and running (though it starts into 1024x768), but LCD screen (DVI) is without signal

Created attachment 31270 [details]
xrandr output

Sorry for the noise, the LCD connector was not properly plugged now (I moved it a little bit). I will test it once more.

Created attachment 31271 [details] [review]
deal with connectors sourced to the same encoder v5

take 5.  As to the LVDS, you should be able to change to the native mode now using xrandr.  you are just ending up with 1024x768 since that's the common mode that both outputs support.

(In reply to comment #38)
> Created an attachment (id=31271) [details]
> deal with connectors sourced to the same encoder v5
> 
> take 5.  As to the LVDS, you should be able to change to the native mode now
> using xrandr.  you are just ending up with 1024x768 since that's the common
> mode that both outputs support.

I was just playing with "take 4" and it looks it is working - I have both LVDS and LCD (DVI) working. My usual steps with xrandr work (change LVDS to 1280x800 and change LCD to use 1280x1024 and be right-of LVDS). THANKS!

I'm going to test the "take 5" now.

Created attachment 31274 [details]
Radeon's Xorg.0.log (radeon git master, bug21767-5.diff applied)

LVDS and LCD (DVI) work as expected

Created attachment 31275 [details]
xrandr output (take 5)

(In reply to comment #38)
> Created an attachment (id=31271) [details]
> deal with connectors sourced to the same encoder v5
> 
> take 5.  As to the LVDS, you should be able to change to the native mode now
> using xrandr.  you are just ending up with 1024x768 since that's the common
> mode that both outputs support.

The "take 5" works too, I see no difference to "take 4" (once more sorry for the noise). Thanks for the great work :-)

Is there anything I should test? Some xrandr/DPMS stuff?

(In reply to comment #42)
> (In reply to comment #38)
> > Created an attachment (id=31271) [details] [details]
> > deal with connectors sourced to the same encoder v5
> > 
> > take 5.  As to the LVDS, you should be able to change to the native mode now
> > using xrandr.  you are just ending up with 1024x768 since that's the common
> > mode that both outputs support.
> 
> The "take 5" works too, I see no difference to "take 4" (once more sorry for
> the noise). Thanks for the great work :-)
> 

Cool.  thanks for testing.

> Is there anything I should test? Some xrandr/DPMS stuff?
> 

make sure dpms works.  try:
sleep 5; xset dpms force off
and make sure both head blank properly and then come back.

(In reply to comment #43)
> make sure dpms works.  try:
> sleep 5; xset dpms force off
> and make sure both head blank properly and then come back.

Works. Both screens (firstly LVDS, in a moment the LCD too) went blank. Both went back (in the same order) when I moved the mouse. I'm now using the "take 5". Should I try the same with "take 4" too?

(In reply to comment #44)
> Works. Both screens (firstly LVDS, in a moment the LCD too) went blank. Both
> went back (in the same order) when I moved the mouse. I'm now using the "take
> 5". Should I try the same with "take 4" too?
> 

No take 5 is fine.  I'll get this committed.

(In reply to comment #45)
> (In reply to comment #44)
> > Works. Both screens (firstly LVDS, in a moment the LCD too) went blank. Both
> > went back (in the same order) when I moved the mouse. I'm now using the "take
> > 5". Should I try the same with "take 4" too?
> > 
> 
> No take 5 is fine.  I'll get this committed.

Thanks. I'm finished with this bug, so feel free to close the bug, if you are satisfied too :-)

Created attachment 31277 [details] [review]
deal with connectors sourced to the same encoder final

This is what I'm going to commit.  Can you make sure it still works properly?  I added support for properly picking HDMI vs. DVI based on the edid.

(In reply to comment #47)
> Created an attachment (id=31277) [details]
> deal with connectors sourced to the same encoder final
> 
> This is what I'm going to commit.  Can you make sure it still works properly? 
> I added support for properly picking HDMI vs. DVI based on the edid.

I'm going to test it now. I will be back after couple of minutes.

Created attachment 31280 [details]
Radeon's Xorg.0.log (radeon git master, bug21767-final.diff applied)

(In reply to comment #47)
> Created an attachment (id=31277) [details]
> deal with connectors sourced to the same encoder final
> 
> This is what I'm going to commit.  Can you make sure it still works properly? 
> I added support for properly picking HDMI vs. DVI based on the edid.

The patch works. I've tried the DPMS command too.

I think it is unrelated and I don't want to extend this bug report with another request, but the first DPMS blanking failed on my LCD screen (it shown bright coloured vertical stripes with big growing white spot in the middle). I've seen this before too (not reproducible), but I don't know if it is problem of my LCD screen or software.

(In reply to comment #49)
> Created an attachment (id=31280) [details]
> Radeon's Xorg.0.log (radeon git master, bug21767-final.diff applied)

I've tried the `sleep 5; xset dpms force off` command twice immediately after KDE startup (the programs were still starting at that time). The first DPMS test had problem (as described above), the second one was good. Then I configured the screen as described in comment #39 and repeated the DPMS test again (with no problems).

I think this bug is fixed.

committed:
437113124bbd6fb166825169eabec4dfde900dd9

Alex, is it possible that the same problem is in KMS? I just tried the kernel with KMS enabled and it booted up without LVDS, with the same symptoms in X. Should I create another bug report for KMS stuff?

(In reply to comment #53)
> Alex, is it possible that the same problem is in KMS? I just tried the kernel
> with KMS enabled and it booted up without LVDS, with the same symptoms in X.
> Should I create another bug report for KMS stuff?
> 

Likely.  I was planning to port the fixes to kms.  Might as well file a bug so we can track it however.

(In reply to comment #54)
> (In reply to comment #53)
> > Alex, is it possible that the same problem is in KMS? I just tried the kernel
> > with KMS enabled and it booted up without LVDS, with the same symptoms in X.
> > Should I create another bug report for KMS stuff?
> > 
> 
> Likely.  I was planning to port the fixes to kms.  Might as well file a bug so
> we can track it however.
> 

I've created bug #25150 for the KMS part.