(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?
(In reply to comment #3) properties also causes the virtual screen daemon' s xrandr plugin configures the screens. daemon, not the driver?
> (In reply to comment #2)
> > Toggling the LCD via gnome-display-
> > size to be correct for the session. It simply should also be set correctly when
> > gnome-settings-
>
> So it sounds like there's an issue in gnome-settings-
>
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?