GNOME Bugzilla – Bug 663740
[fglrx] multi-monitor: Unable to position top-bar on right-hand monitor
Last modified: 2012-03-10 17:28:57 UTC
Created attachment 201104 [details] xorg configuration file The top-bar refused to be positioned on the right-hand monitor, no matter what I try. OS: Ubuntu 11.10 (x86) Video card: ATI/AMD HD6950 Video driver: AMD CCC 11.09 I have two identical monitors connected, labelled DFP4 and DFP5 in xrandr, where the video card threats DFP5 as its primary by default. DFP4 is positioned left of DFP5. In the GNOME display settings the black bar is positioned on the right-hand monitor (DFP5). The file "~/.config/monitors.xml" also has the primary monitor set accordingly. In AMDCCC the right-hand monitor (DFP5) is defined as monitor 1, whereas the left-hand monitor (DFP4) is 2. Executing "xrandr --output DFP5 --primary" has no effect, while settings other properties for that monitor does work. If I turn the monitors around, through either the AMDCCC or using xrandr, and say that DFP4 is primary, which is then positioned on the right-hand side, the top-bar is yet again moved to the left-hand monitor (DFP5). As a test I also tried positioning the monitors above each other. In this case the top-bar will always be positioned on the top monitor, even if I tell it to position it on the bottom one. I've also tried different ways of configuring the xorg.conf file to mark the right-hand monitor as primary, but yet again to no avail. Attached you'll find various logs and config files. Let me know if you need any more information.
Created attachment 201105 [details] xorg log file
Created attachment 201106 [details] Output of 'xrandr -q --verbose'
Created attachment 201107 [details] display settings '~/.config/monitors.xml' file
Minor correction: the video driver is AMD CCC 11.10
I assume you tried dragging the top panel to the other monitor?
To me this looks like a fglrx bug in its randr implementation. Can you try deleting your ~/.config/monitors.xml and moving your xorg.conf aside (i.e. as if you didn't have a xorg.conf) and try again? This really should just work without config files if the driver cooperates.
(In reply to comment #5) > I assume you tried dragging the top panel to the other monitor? Yes. Nothing happens when I drag the top-bar to the left-hand monitor, the top-bar remains in position on the left-hand monitor. If I apply these settings followed by dragging the top-bar back to the right-hand monitor again, things get really messy. Unlike when dragging it the the left-hand monitor, the screens go black for a second, as in actually configuring. When becoming active again the screens have been turned around (i.e. DFP5 on the right-hand side becomes DFP5 on the left-hand side), the top-bar is positioned on DFP5, and the mouse-pointer disappears, remaining only visible within 15px to 25px of the outer edges of the screen (right edge of right-hand monitor, left edge of left-hand). The mouse-pointer does remain active though. With a bit of luck I can still press the confirmation button. Logging out and in again in this state reverts everything again. Dragging monitor DFP5 to the right-hand side of DFP4 in this state leaves DFP5 effectively, though not visually in the "Displays" settings, positioned on the left-hand side. It does restore mouse-pointer visibility however. (In reply to comment #6) > Can you try deleting your ~/.config/monitors.xml and moving your xorg.conf > aside (i.e. as if you didn't have a xorg.conf) and try again? If I try using just the GNOME "Displays" settings and disable the "Mirror displays" option, the resulting error will be: "The selected configuration for displays could not be applied:required virtual size does not fit available size: requested=(2560, 1024), minimum=(320, 200), maximum=(1280, 1280)" When doing the same with AMDCCC this error does not occur. Using AMDCCC, however, results in the generation and use of xorg.conf. Maybe if just this error can be resolved, all will function properly through the "Displays" settings.
(In reply to comment #7) > If I try using just the GNOME "Displays" settings and disable the "Mirror > displays" option, the resulting error will be: > > "The selected configuration for displays could not be applied:required virtual > size does not fit available size: requested=(2560, 1024), minimum=(320, 200), > maximum=(1280, 1280)" Right, that's why the AMD tool puts a Virtual entry in your xorg.conf: SubSection "Display" Viewport 0 0 Virtual 2560 2560 Depth 24 EndSubSection This entry tells the driver the maximum width and height for the frame buffer. Open source drivers don't have this limit, they set this dynamically as far as the hardware allows. In short, use the open source driver if you can. Actually, you can test a live CD (say Fedora 16) and easily check if the open source driver would work better for you.
(In reply to comment #8) > In short, use the open source driver if you can. That's not an option, nor a solution. 3D performance and video acceleration for the open source driver is still too far behind. I also find it hard to believe that a video driver is the cause of something like incorrect positioning of the GNOME top-bar. Is it really something that should be addressed at ATI/AMD? Is there in intermediate solution possible where e.g. just the frame buffer is set/forced through xorg.conf, or any other way, and all the rest is handled through GNOME/xrandr?
(In reply to comment #8) > Actually, you can test a live CD (say Fedora 16) and easily check if the open > source driver would work better for you. (In reply to comment #9) > That's not an option, nor a solution. 3D performance and video acceleration for > the open source driver is still too far behind. > I also find it hard to believe that a video driver is the cause of something > like incorrect positioning of the GNOME top-bar. You can find out if it has an influence by trying the other driver. :)
(In reply to comment #9) > (In reply to comment #8) > > In short, use the open source driver if you can. > > That's not an option, nor a solution. 3D performance and video acceleration for > the open source driver is still too far behind. > > I also find it hard to believe that a video driver is the cause of something > like incorrect positioning of the GNOME top-bar. > Is it really something that should be addressed at ATI/AMD? Apparently fglrx supports XRANDR up to 1.2 which does not have way to set/query a "primary monitor". So the monitor with the first index is taken as primary. So yeah this should be fixed in the driver.
I still have to try out a live cd with GNOME 3.2 but I will do soon, to see how the open source driver holds up in this respect. I'll contact ATI about the issue afterwards. According to an article from October 2009 [1], fglrx already got initial support for randr 1.3 at that time. This would mean that nothing has happened for more then two years. I can imagine, however, that flgrx will not be the only one not supporting randr 1.3 (fully). Would that not be sufficient reason for GNOME to provide a fall-back? Until GNOME 3.0 all worked fine despite randr 1.3 support, so there must a way. Which index are we talking about exactly? If there any way to influence this index? [1] http://www.phoronix.com/scan.php?page=news_item&px=NzYzMg
Confirming the absence of the issue when using the open source drivers. It is functioning properly with those drivers. I've reported the issue at ATI and supplied a link to this issue.
After some e-mailing back and forth, AMD's reply: "Our official statement is that we do not officially support GNOME3, since none of our supported distributions use it by default. Unbuntu 11.10 is the first one to ship with this product, but it does not use Gnome3 by default. Unofficially we do know that an OPENGL team is working on GNOME issues that we have reported to them in previous cases." With the latest release of openSUSE and Fedora things are different now, GNOME 3 is default. Hopefully this will change AMD's current GNOME 3 support state. I do, however, doubt (full) randr 1.3 support will have high priority based on the amount of, more prominent, rendering issues.
For the record: No changes in AMD Catalyst 11.12, "--primary" still has no effect, even though this release supposedly has some randr fixes [1]. [1] http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzk
Age, have you tried the just released 12.1 fglrx driver? Does the issue persist? You may want to file a bug report at http://ati.cchtml.com requesting full xrandr 1.3 support.
(In reply to comment #16) > Age, have you tried the just released 12.1 fglrx driver? > Does the issue persist? > The issue does persist in 12.1, unfortunately. > You may want to file a bug report at http://ati.cchtml.com > requesting full xrandr 1.3 support. I linked to this report in the bug tracker on that site a while back. An AMD employee requested separate issue reports in an existing issue report [1]. They should be aware of this issue now. It wouldn't hurt to file a new report over there though, just in case, for their ease of tracking. [1] http://ati.cchtml.com/show_bug.cgi?id=99#c142
@Christian: FYI, http://ati.cchtml.com/show_bug.cgi?id=413
That report looks good to me. Let us see what they are going to do about it.
FYI: Lovely, the issue is fixed in 12.2. See the following forum post and the follow-up for more info: http://phoronix.com/forums/showthread.php?69205-AMD-Catalyst-12-2-For-Linux-Brings-Few-Changes&p=253535#post253535