Bug 20224

Summary: [Mobility X700] Virtual screen size too small when using dual head on 6.11.0
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: q3aiml
Version: 7.3 (2007.09)   
Hardware: Other   
OS: Linux (All)   
URL: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/277948
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log none

Description Bryce Harrington 2009-02-19 13:56:36 UTC 
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
Comment 1 Alex Deucher 2009-02-19 15:15:05 UTC 
Is this when running compiz?  the desktop size exceeds the 3D engine limits.
Comment 2 Andy Clayton 2009-02-19 20:50:58 UTC 
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.
Comment 3 Michel Dänzer 2009-02-20 00:25:30 UTC 
(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?
Comment 4 Andy Clayton 2009-02-22 19:40:23 UTC 
(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?
Comment 5 Alex Deucher 2009-11-11 10:52:36 UTC 
Is this still an issue with xf86-video-ati from git master or a newer xserver?
Comment 6 Andy Clayton 2009-12-10 22:36:54 UTC 
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.