Created attachment 23120 [details] [review] Xorg.0.log Forwarding this report from a Ubuntu reporter: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/277948 [Problem] Upon disabling mirroring and logging back in, the virtual screen size is that of one screen, not both. This was confirmed as still happening on 6.11.0, but was first reported on Ubuntu Intrepid on 2008-10-03 [xrandr output] Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 3360 x 1050 LVDS connected 1680x1050+1680+0 (normal left inverted right x axis y axis) 331mm x 207mm DVI-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm For things to behave properly, Screen 0 needs to be 3360x1050, which can be manually set using xrandr --output S -s 3360x1050. Having this wrong breaks the nautilus desktop, for example. [Original Report] Binary package hint: nautilus Using Intrepid with the open source ati driver, two screens, and compiz enabled results in nautilus only running on one screen. I configured dual head using the Monitor Resolution Settings program. After restarting X for a virtual screen size config write, I come back in to find that one desktop is not getting redrawn. So dragging a window across the broken desktop results in the window contents getting drawn across the desktop, for example. Otherwise the screen itself works fine: Panels can be moved on and they function fine. I can use all the programs I want on the screen, and move other ones on to it. Using "xprop | grep WM_CLASS" on the working desktop returns WM_CLASS(STRING) = "desktop_window", "Nautilus" while using it on the broken desktop returns nothing. It seems that nautilus is simply not running on the one screen. I've confirmed I have 6.11.0 in my Xorg.log, and while the update unfortunately did not fix the issue, I did find something in testing: attempting to turn off the LCD in Display Settings takes an inordinate amount of time to fail, but afterwards the screen size is set correctly. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 8.10 Uname: Linux 2.6.27-4-generic i686
Is this when running compiz? the desktop size exceeds the 3D engine limits.
Hi Alex, I'm the original reporter -- no, it's not. I disabled compiz due to that and various other issues. It seems simply a mistake that the virtual screen size is not set correctly. The virtual screen size does not appear to be restricted to what the 3d engine can handle as it can manually be set to 3360x1050 for the duration of the current session using xrandr. Toggling the LCD via gnome-display-properties also causes the virtual screen size to be correct for the session. It simply should also be set correctly when gnome-settings-daemon's xrandr plugin configures the screens. At the advice of Bryce Harrington I'm going to be trying to reproduce this shortly without g-s-d so I can give the xrandr command(s) which setup dual head and cause it to have the wrong virtual screen size.
(In reply to comment #2) > Toggling the LCD via gnome-display-properties also causes the virtual screen > size to be correct for the session. It simply should also be set correctly when > gnome-settings-daemon's xrandr plugin configures the screens. So it sounds like there's an issue in gnome-settings-daemon, not the driver?
(In reply to comment #3) > (In reply to comment #2) > > Toggling the LCD via gnome-display-properties also causes the virtual screen > > size to be correct for the session. It simply should also be set correctly when > > gnome-settings-daemon's xrandr plugin configures the screens. > > So it sounds like there's an issue in gnome-settings-daemon, not the driver? > Well gnome-settings-daemon simply calls RandR apis to toggle and position the screens. It is possible that g-s-d merely abuses RandR and breaks it, which is why I will hopefully have time this week to do as Bryce suggested and reproduce the problem using only xrandr. I'm guessing this was assumed to be the driver as others do not experience the same problem. It does seem clear, though, that something is bugged in either RandR or the driver when the usable desktop/screen size is clearly 3360x1050, yet it continues to report 1680x1050, right?
Is this still an issue with xf86-video-ati from git master or a newer xserver?
I am no longer using this hardware, actually, so I'll close it unless someone else can reproduce.
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.