Created attachment 337529 [details]
dmesg after testing
Description of problem:
I have two monitors: Monitor A: Laptop: 1400x1050
Monitor B: LCD: 1280x1024
Mirror mode works out of the box with a resolution of 1024x768.
With the same resolution and mirror mode off, the laptop screen remains black, but the mouse pointer is visible and i can move windows on it and back.
If i use different resolutions, parts of one screen are visible on both monitors, the remaining space is black.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
ATI Technologies Inc Radeon Mobility X1400 [1002:7145]
Created attachment 337530 [details]
Created attachment 337532 [details]
Created attachment 337537 [details]
output of xrandr --verbose
I have 2 24" Samsung monitors, I have a similar problem.
Created attachment 337565 [details]
xrandr after first boot up
Created attachment 337566 [details]
verbose xrandr after a multi screen setup attempt
Created attachment 337575 [details]
I have three monitors: Monitor A: Laptop: 1400x1050
Monitor B: LCD: 1280x1024 - dvi
Monitor C: LCD: 1280*1024 - analog
I wasn't able to see an output on Mon B in neither mode.
In mirror mode I was once able to same the same on A and C (1024*768), but was unable to repeat it.
On Monitor A I miss the 1280*1024 mode.
The GUI interface in mirror mode doesn't allow to switch individual monitors on/off.
Also, in a Lenovo T60p with ATI Technologies Inc M56GL [Mobility FireGL V5200] [1002:71c4]. In multihead mode, the logical left-hand screen looks correct but the other screen remains black, except for the cursor
Created attachment 337610 [details]
This bug describes the problems I am seeing as well. Attaching log files.
-rw-rw-r-- liveuser/liveuser 657 2009-04-01 18:27 tmp/xrandr.out
-rw------- liveuser/liveuser 2484 2009-04-01 18:19 home/liveuser/.xsession-errors
-rw-r--r-- root/root 396724 2009-04-01 18:27 var/log/Xorg.0.log
-rw------- root/root 94390 2009-04-01 18:27 var/log/messages
-rw-r--r-- root/root 46912 2009-04-01 18:14 var/log/dmesg
Created attachment 337637 [details]
Created attachment 337638 [details]
Created attachment 337639 [details]
Created attachment 337640 [details]
Switching priority to high because this represents a major
loss of functionality.
All logs included, switching to ASSIGNED.
Fedora Bugzappers volunteer triage team
*** Bug 493508 has been marked as a duplicate of this bug. ***
For me with ATI Technologies Inc RV516 [Radeon X1300/X1550 Series] it worked with
The problem was introduced with
The problem remains with
So I think the problem is in the kernel - but I am sure airlied can solve it no matter where it is ;-)
Can others try to boot an old kernel and confirm that it works there and thus help pointing out what introduced the problem?
I also notice different behaviour depending on how the displays are (logically!) placed next to each other. With secondary-to-the-right-of-primary the secondary is black. With secondary-on-top-of-primary I get "something" on both displays, but both have some rendering problems.
can we get a re-test with -103 kernel or higher? I've done a lot of fixes in this area.
I'm actually running 102 on a ThinkPad T60p with a Mobility FireGL V5200 as my personal laptop.
Things are very much better and the remaining problems may not be due to the radeon driver at all but to other components.
1/ Booting dual screen doesn't pick up the preferred resolution.
2/ Once when booting, and also in other circumstances, I've got the screens to partially overlap. I don't think this is a *problem* per se, but it does look weird, particularly as the gnome tool for moving screens around is so particular to prevent overlapping screens.
3/ When rotating a screen, the tool "greys" out the rotation button until you switch between screens or do some other actions.
I'll wait until 103 hits and then do a full test.
I'm running 18.104.22.168-104.fc11.x86_64 on my laptop with RS690M (Radeon X1200 Series).
It is definitely a big improvement. On the Radeon test day I got black areas on one of the monitors. Now I could change the relative positions of the monitors several times and it worked every time, no black areas, everything nice.
Some remaining problems (not likely to be related to this bug):
1) At one point after applying another monitors settings, my desktop session got stuck and one of the Gnome panels was redrawing rapidly. I had to use CTRL+ALT+BackSpace ;-) This could be a bug in Gnome - it could have been confused about where to put the panel after the monitor reconfiguration.
2) I tried rotation too. It worked, but drawing on the rotated monitor was very slow, probably completely unaccelerated. Is acceleration supposed to work with rotation?
I can confirm that multihead now works for me. I am using 102.
I had a "funny" issue though.
In the past I had used gnome-display-properties to disable my laptop screen, leaving only my external LCD. This was to get around the multihead issues.
When I upgraded to >70, upon login BOTH displays were BLACK. This made it hard to do anything. I tried to login via ssh and shutdown the machine, but the machine would not shutdown (I think there is another bug about failing to shutdown).
I fixed this issue by booting with .70, using gnome-display-properties to select mirror and then rebooted into 103 where I could now login and even select dual monitors!
Could this be a problem for others upgrading to F11? Should I log another bug?
Isn't this issue solved in rawhide and ready to be closed as such?
Other issues should be filed separately.
I concur. Things have been great in this area for a few rawhides now.
Reporter, could you please confirm, that this has been fixed in the last updates?
I reported a duplicate bug and everything is working for me on current rawhide.
Thanks for letting us know, but I would prefer to hear it from the original reporter of this bug.
sorry, but i can't test it because i don't have fedora on my laptop. i've tested it with the radeon test day livecd and i've tried to test it with preview release livecd but it can't boot because of bug #499149.
(In reply to comment #26)
> Thanks for letting us know, but I would prefer to hear it from the original
> reporter of this bug.
I was the original reporter of the duplicate bug... isn't the point of closing bugs as duplicate to achieve input from multiple testers on an issue?
(In reply to comment #28)
> I was the original reporter of the duplicate bug... isn't the point of closing
> bugs as duplicate to achieve input from multiple testers on an issue?
Truth to be told, it isn't ... the main point of deduplication is to help us to survive sheer number of bugs we have to deal with, but yes, I am not closing this bug, because original reporter has better things to do with his life than to slave on Fedora bug testing ;-).
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
i've tried the fedora 11 livecd and it works perfectly.
thanks and keep up the great work
Thank you very much for testing again.
Switching status to CLOSED/CURRENTRELEASE.
Fedora Bugzappers volunteer triage team