Hey, folks. Just wanted to flag up this bug before we hit the change deadline:
https://bugzilla.redhat.com/show_bug.cgi?id=623824
it seems that the default policy for multiple monitors in current F14 is not to use them at all (see https://bugzilla.redhat.com/show_bug.cgi?id=623824#c15 ). On the face of it, this seems like an unintentional change from previous policy. Is this actually the case? If so, can someone submit a fix, quick? :) If it's an intentional change, it should be announced/documented for the release...
On Tue, Oct 12, 2010 at 9:19 PM, Adam Williamson awilliam@redhat.com wrote:
Hey, folks. Just wanted to flag up this bug before we hit the change deadline:
https://bugzilla.redhat.com/show_bug.cgi?id=623824
it seems that the default policy for multiple monitors in current F14 is not to use them at all (see https://bugzilla.redhat.com/show_bug.cgi?id=623824#c15 ). On the face of it, this seems like an unintentional change from previous policy. Is this actually the case? If so, can someone submit a fix, quick? :) If it's an intentional change, it should be announced/documented for the release...
Now that you mention it (and I might be hallucinating) I think I've noticed this when in the office on my docking station when I boot up in the morning but when I log in I get my usual (saved?) config of spanning of both screens (I'm not sure if that is due to a historical saved config). When I resume (even when docking from not being in the docking station) it seems to come back to dual screen just fine. I didn't really notice the lack of second screen for login as I'm generally not there that long and it sort of seems eco to have only one screen to deal with a login dialog as long as it restores the default for the profile or defaults to using both for a new profile.
Peter
PS massive kudos to X/power and other developers for the last couple of releases with perfect dual screen in F-13 (and even better in F-14) and good suspend (looking great in F-14) it makes the week at work much nicer (despite crappy BIOS ACPI tables!).
On Tue, 2010-10-12 at 13:19 -0700, Adam Williamson wrote:
Hey, folks. Just wanted to flag up this bug before we hit the change deadline:
https://bugzilla.redhat.com/show_bug.cgi?id=623824
it seems that the default policy for multiple monitors in current F14 is not to use them at all (see https://bugzilla.redhat.com/show_bug.cgi?id=623824#c15 ). On the face of it, this seems like an unintentional change from previous policy. Is this actually the case? If so, can someone submit a fix, quick? :) If it's an intentional change, it should be announced/documented for the release...
To me, given the commit: http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-2-32&i... it certainly doesn't look intentional.
And it shouldn't be changing the already existing monitor setup, that's certain.
On Wed, 2010-10-13 at 01:24 +0100, Bastien Nocera wrote:
On Tue, 2010-10-12 at 13:19 -0700, Adam Williamson wrote:
Hey, folks. Just wanted to flag up this bug before we hit the change deadline:
https://bugzilla.redhat.com/show_bug.cgi?id=623824
it seems that the default policy for multiple monitors in current F14 is not to use them at all (see https://bugzilla.redhat.com/show_bug.cgi?id=623824#c15 ). On the face of it, this seems like an unintentional change from previous policy. Is this actually the case? If so, can someone submit a fix, quick? :) If it's an intentional change, it should be announced/documented for the release...
To me, given the commit: http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-2-32&i... it certainly doesn't look intentional.
And it shouldn't be changing the already existing monitor setup, that's certain.
I think if you've ever gone into display preferences and changed anything you'll have a stored setup so the change of the default won't affect you. Possibly if you've never had occasion to do that, though, you'd have seen changed behaviour on the update which changed the default.
Personally I have a two-monitor setup and I never saw this bug, but I'm fairly certain my config got written out to gconf so it makes sense that I wouldn't see it.
Given how it got introduced (via the commit you pointed out), I guess it'd make the most sense for us to ship an update which changes the default to 'true', and report this upstream? Perhaps Joey didn't realize this change has the effect of changing the previous default behaviour. (I think previously the default was 'whatever X does', and for most people/distros the X default would have been 'clone'; I think for Fedora 13, the default was 'span'. Either way, it's not 'turn it off'.)
On Tue, 2010-10-12 at 17:53 -0700, Adam Williamson wrote:
Given how it got introduced (via the commit you pointed out), I guess it'd make the most sense for us to ship an update which changes the default to 'true', and report this upstream? Perhaps Joey didn't realize this change has the effect of changing the previous default behaviour. (I think previously the default was 'whatever X does', and for most people/distros the X default would have been 'clone'; I think for Fedora 13, the default was 'span'. Either way, it's not 'turn it off'.)
Looking at the code, if we change both keys to default to true, we'll end up with clone mode. If thats ok, we can do that. Its not 'whatever X does' either, though.
Matthias Clasen (mclasen@redhat.com) said:
Given how it got introduced (via the commit you pointed out), I guess it'd make the most sense for us to ship an update which changes the default to 'true', and report this upstream? Perhaps Joey didn't realize this change has the effect of changing the previous default behaviour. (I think previously the default was 'whatever X does', and for most people/distros the X default would have been 'clone'; I think for Fedora 13, the default was 'span'. Either way, it's not 'turn it off'.)
Looking at the code, if we change both keys to default to true, we'll end up with clone mode. If thats ok, we can do that. Its not 'whatever X does' either, though.
It sounds better than 'off' to me, at least. And clone mode is easier to fix into span mode than span is easier to fix into clone mode, if something goes wrong.
Bill
On Fri, 2010-10-15 at 13:47 -0400, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
Given how it got introduced (via the commit you pointed out), I guess it'd make the most sense for us to ship an update which changes the default to 'true', and report this upstream? Perhaps Joey didn't realize this change has the effect of changing the previous default behaviour. (I think previously the default was 'whatever X does', and for most people/distros the X default would have been 'clone'; I think for Fedora 13, the default was 'span'. Either way, it's not 'turn it off'.)
Looking at the code, if we change both keys to default to true, we'll end up with clone mode. If thats ok, we can do that. Its not 'whatever X does' either, though.
It sounds better than 'off' to me, at least. And clone mode is easier to fix into span mode than span is easier to fix into clone mode, if something goes wrong.
I guess we should ask Novell why they chose 'off' as the default. The other thing I'd like to clarify is if the code actually backs up its implicit claim of being restricted to 'laptop+external monitor" cases: is there really code in there to distinguish these from any other multihead case?
note that the X default to span was intentionally chosen by I think ajax during f13 cycle, so he presumably wants that to be the default...
On Fri, 2010-10-15 at 10:59 -0700, Adam Williamson wrote:
note that the X default to span was intentionally chosen by I think ajax during f13 cycle, so he presumably wants that to be the default...
"Meh". I prefer spanning to cloning in general because (in general) cloning isn't something you can do reliably. But we also can't reliably know output connection state in all cases, so the login manager kinda wants a logical clone kind of config where the login dialog is visible everywhere. You can't win, you can only pick how you lose.
- ajax
On Fri, 2010-10-15 at 10:59 -0700, Adam Williamson wrote:
On Fri, 2010-10-15 at 13:47 -0400, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
Given how it got introduced (via the commit you pointed out), I guess it'd make the most sense for us to ship an update which changes the default to 'true', and report this upstream? Perhaps Joey didn't realize this change has the effect of changing the previous default behaviour. (I think previously the default was 'whatever X does', and for most people/distros the X default would have been 'clone'; I think for Fedora 13, the default was 'span'. Either way, it's not 'turn it off'.)
Looking at the code, if we change both keys to default to true, we'll end up with clone mode. If thats ok, we can do that. Its not 'whatever X does' either, though.
It sounds better than 'off' to me, at least. And clone mode is easier to fix into span mode than span is easier to fix into clone mode, if something goes wrong.
I guess we should ask Novell why they chose 'off' as the default. The other thing I'd like to clarify is if the code actually backs up its implicit claim of being restricted to 'laptop+external monitor" cases: is there really code in there to distinguish these from any other multihead case?
note that the X default to span was intentionally chosen by I think ajax during f13 cycle, so he presumably wants that to be the default...
We discussed this upstream, and we actually want to default to leaving Xorg to setup the monitors how it pleases by default.
So this is how it's now going to be setup in the F14 update, and in GNOME 3 (see https://bugzilla.gnome.org/show_bug.cgi?id=634092 for the GNOME 3 changes).
Cheers
On Fri, 2010-11-05 at 16:24 +0000, Bastien Nocera wrote:
note that the X default to span was intentionally chosen by I think ajax during f13 cycle, so he presumably wants that to be the default...
We discussed this upstream, and we actually want to default to leaving Xorg to setup the monitors how it pleases by default.
So this is how it's now going to be setup in the F14 update, and in GNOME 3 (see https://bugzilla.gnome.org/show_bug.cgi?id=634092 for the GNOME 3 changes).
Thanks for the note. Could you poke me when the update goes through so I can update the Common Bugs page? Thanks.
desktop@lists.fedoraproject.org
-
Adam Jackson -
Adam Williamson -
Bastien Nocera -
Bill Nottingham -
Matthias Clasen -
Peter Robinson