Description of problem: A somewhat recent update (not sure which, best guess is the component I filed this against) has rendered dual screen spanning wallpapers impossible. No matter what the background is set to display as, it will repeat the background on both monitors instead of one background for both. Version-Release number of selected component (if applicable): 1.7.1-7 How reproducible: Very, if you have two monitors. I am using an nVidia Geforce 8600, proprietary and nouveau have no difference. Steps to Reproduce: 1. Update Fedora 12 packages. 2. Try to make the wallpaper span across both screens. Actual results: Wallpaper always repeats, no matter which setting is used. Expected results: At least one setting should allow the wallpaper to span across both screens. If you use a Live CD you should be able to see the expected behavior there. Additional info: Ironically, it looks like they fixed bug 520341 at the expense of original spanning behavior.
I see the same issue - a 3200x1200 wallpaper has the left hand 1600x1200 pixels rendered twice, once per screen.
I see the same issue. I have a left 1440x900 laptop screen and a right 2560x1600 30" monitor. Thus I had a 4000x1600 background (that was tiled, and thus displayed correctly). It now gets trimmed to the central 2560x1600, then tiled across both monitors. As a result of this I get a junk display on both screens. ie. Background image: ABCDabcdefgh EFGHijklmnop IJKLqrstuvwx ----yzabcdef ----ghijklmn which used to display as ABCD EFGH IJKL on the small left screen, and abcdefgh ijklmnop qrstuvwx yzabcdef ghijklmn on the large right screen, now displays as if the background was (ie. trimming to size of largest screen) CDabcdef GHijklmn KLqrstuv --yzabcd --ghijkl which proceeds to be displayed as if it was tiled like this: CDabcdefCDabcdef GHijklmnGHijklmn KLqrstuvKLqrstuv --yzabcd--yzabcd --ghijkl--ghijkl which gives CDab GHij KLqr on the small left screen, and cdefCDab klmnGHij stuvKLqr abcd--yz ijkl--gh on the large right screen. Which as you can see is junk. I can't find any way to workaround this. Indeed this is pretty terrible with two screens of different size, because it will never do the correct thing.
Please note, that while the graphical configuration of the background, appears to be provided by: gnome-appearance-properties --show-page=background which is a part of control-center, this appears to be a problem much farther down the stack, since I can change the background directly via: gconftool-2 -s /desktop/gnome/background/picture_filename -t string /path/name.png and it is still quite broken.
(I also doubt this is an X server bug, but I don't know what is actually responsible for rendering the background... gnome-session? metacity?)
I've fixed the issue by downgrading some packages, I believe the problem is in gnome-desktop Ie. the following works: # rpm -q nautilus nautilus-extensions gnome-desktop nautilus-2.28.2-2.fc12.x86_64 nautilus-extensions-2.28.2-2.fc12.x86_64 gnome-desktop-2.28.1-3.fc12.x86_64 (I should have also downgraded control-center to maintain deps, but I ignored that) While the state before when it was broken was: # yum check-update gnome-desktop.x86_64 2.28.2-3.fc12 updates nautilus.x86_64 2.28.4-1.fc12 updates nautilus-extensions.x86_64 2.28.4-1.fc12 updates
To be more precise, further bisection shows that the following setup works (with everything fully updated, with the exception of gnome-desktop-2.28.1-6.fc12.x86_64 [note: fully updated nautilus and nautilus-extensions - so the problem is not there] while upgrading one step further to: gnome-desktop-2.28.1-7.fc12.x86_64 breaks it. The changelog for gnome-desktop available at http://koji.fedoraproject.org/koji/buildinfo?buildID=150086 reinforces this idea. The comment at 2.28.1-7 is: * Sun Dec 13 2009 Jon McCann <jmccann> - 2.28.1-7 - Better per-monitor backgrounds patch (gnome #147808)
> Ironically, it looks like they fixed bug 520341 at the expense of original > spanning behavior. There's no 'they' here, its just us. And yes, spanning behaviour was considered much less useful than a working repeat. You can still get something like spanning behaviour by selecting 'Tile' as the style. In that case the image won't be repeated on each monitor. But it won't be scaled to fit either, so you have to have an image that has the right dimensions for your dual-monitor setup already. I think a patch to add 'Spanned' as a style option would probably be considered.
"Tile" worked the way you describe until recently, it seems to have been broken since gnome-desktop-2.28.1-7 as Maciej noted above. The old Tile behavior is totally fine by me.
I fail to see how the current behaviour of "Tile" is useful with multiple screens. I can understand wanting different behaviour for the remaining modes, but for "Tile"? I can't think of a case where I would want "Tile" to behave like it currently does in favour of the old behaviour.
> You can still get something like spanning behaviour by selecting 'Tile' as the > style. In that case the image won't be repeated on each monitor. But it won't > be scaled to fit either, so you have to have an image that has the right > dimensions for your dual-monitor setup already. See pictures and description above. This is not quite how it currently works. The image you select gets pseudo-randomly trimmed (I haven't quite figured out the logic here, but I think it's take larger screens size, and take a trimmed image of that size from the centre of the selected image), then gets tiled across both screens. The problem is the _trimming_. If your right screen is larger, then you trim the image to the larger screen then tile it across first the small left, then the large right screen -> it looks like junk on *both* screens. I understand and support the changes that have been made to all the other modes. I only don't like/understand/see the need for the changes to the behaviour on 'Tile'.
Assigning to apparently more appropriate component.
Since upgrading to Fedora 12, I've been having this problem, too. It's been driving me crazy. Is there any hope of having something that works for all situations. If not, would it at least be possible to have the old working behavior back (with spanning)?
*** Bug 560436 has been marked as a duplicate of this bug. ***
This is all caused by the "upstream" (gnome) changing the way wallpapers are done and they intentionally broke wide screen wallpapers due to some users didn't like having to build a wide image for their dual monitor setup.. If you look at the gnome bug report https://bugzilla.gnome.org/show_bug.cgi?id=147808 MANY other people are very frustrated with this as well. My only workaround has been telling nautilus to NOT control my desktop (thus having no icons on the desktop) And then I have Compiz render the background image which DOES span both monitors correctly. Of course I can only use this workaround on one of my systems as the other has a crappy on-board vid card that doesn't have enough shared mem to drive two monitors with compiz.
Created attachment 390116 [details] patch adding a "spanned" option for picture_options I am attaching a spanned-background.patch which adds a "spanned" option to the gconf key /desktop/gnome/background/picture_options. The spanned picture option produces the behavior desired by people with dual-screen wallpaper images. The patch does not add the "spanned" option to the schema for /desktop/gnome/background/picture_options (I'm not sure which package this is in, and it would be an easy change anyway). The patch also does not add support for the "spanned" option to the gnome-appearance-properties panel, although this also seems like a fairly easy change. However, the patch does allow the option to be set with gconf-editor or gconftool-2, and in my testing it seems to work perfectly. I hope that this patch adequately addresses the problem and can be included in Fedora and upstream.
Hi, Would you mind posting this patch upstream?
Ray, I have now added this patch to bug #147808. Do you have any recommendations on how to make sure this gets noticed? Is there any chance of it being included in Fedora in the meantime?
It won't go unnoticed. It may not get responded to immediately. We can potentially include the fix in Fedora once it's clear it's set to go upstream.
I've now also added it to GNOME bug #630551.
Ray, in the meantime, would it be possible to revert per-monitor-background.patch? This seems to have hurt a lot more people than it's helped.
By the way, I've just posted a comment to bug #558596 to the effect that per-monitor-background.patch seems to have introduced a big memory leak in gnome-settings-daemon.
We definitely should fix the leak. I do recognize that the existing behavior is suboptimal for you and others who have carefully crafted wallpapers designed to span in the orientation of your monitor configuration, but the old behavior is suboptimal for a large number of wallpapers as well. Bottom line is I think we need to fix this, and I appreciate your contribution toward that end, but I don't think we should revert as a stopgap. Note there is a workaround. A user can choose "Tile" and then the wallpaper will span. As long as the wallpaper is designed for the current monitor layout and geometry, it should work.
There is no workaround, precisely "Tile" is broken.
I start missing this option, since i installed F12 from F10, first i think it was about noveau, get 2 hours disabling it and installing the original Nvidia drivers, and i get the same behaviour. I also try all the options in the wallpaper setup screen and there is no solution. I want to have 2 different wallpapers like i have it before upgrading....
(In reply to comment #22) > We definitely should fix the leak. > > I do recognize that the existing behavior is suboptimal for you and others who > have carefully crafted wallpapers designed to span in the orientation of your > monitor configuration, but the old behavior is suboptimal for a large number of > wallpapers as well. > > Bottom line is I think we need to fix this, and I appreciate your contribution > toward that end, but I don't think we should revert as a stopgap. > Ray, where are there bug reports for folks claiming the old behavior was "sub-optimal" enough to not revert this change? > Note there is a workaround. There is no work around without a program change. Please accept the new patch or revert the old one until the new patch is accepted. I don't see why there is any hesitation. It'll be weeks before the Gnome folks get around to look at it and probably months before it's committed.
(In reply to comment #25) > Ray, where are there bug reports for folks claiming the old behavior was > "sub-optimal" enough to not revert this change? I believe Ray may be referring to bug 520341, which requested an option to center/duplicate an image on both monitors. Currently, Centered achieves this. Since a bug was filed to request this feature, we definitely want to keep it. This situation seems somewhat confusing, I think, because the ability to center an image across two monitors using the "Centered" and "Scaled" options was broken some time ago. At that point I switched to the "Tile" option. This bug report was specifically because after a recent update, "Tile" stopped working, and thus at this point there is no option to span a wallpaper across two monitors. My apologies if I didn't make that clear. Jose Alberto, this bug does not discuss the ability to have two different wallpapers. If you want to use two wallpapers at once, make sure to file a separate bug if one does not already exist.
(In reply to comment #26) > Since a bug was filed to request this feature, we definitely want to keep it. > Ah... these type of bug reports. RFE's that cause regressions that the maintainer doesn't feel are "big enough" to revert the RFE. I hate these type of bug reports. Now we have an RFE to undo the RFE. How helpful was the original RFE? Perhaps a better RFE policy needs to be in place. Anyway: The new patch does not revert the RFE. It will add the "broken" (according to how it worked in <2.28.1-6) behaviour to "span" option and keep the RFE.
(In reply to comment #25) > Ray, where are there bug reports for folks claiming the old behavior was > "sub-optimal" enough to not revert this change? > The issue here is the bug report was in the GNOME bug system and this is an upstream change causing this havoc. The original gnome bug was from like 2004 and I guess someone got into a whimsy and decided to "implement it" and push it as a patch release changing system behavior where it should not have changed.
FYI, gnome-desktop-2.28.2-5.fc12.x86_64, does not seem to fix the problem for me. I've downloaded the x86_64 package from koji, upgraded to it and run: gconftool-2 -s /desktop/gnome/background/picture_options -t string spanned and killed and restarted nautilus, and no joy (I verified spanned shows up in strings /usr/lib64/libgnome-desktop-2.so.11.4.2 | egrep spanned) The same sequence [dowgrading back to 2.28.1-6, switching back to 'wallpaper' and killing and restarting nautilus] works for the downgrade, so the problem is definitely the package. 'spanned' seems to behave exactly the same as 'centered' - each screen is separately being shown with a huge wallpaper of which the central part is shown centered on screen.
Maciej, why did you pull from koji? The updates are in updates-testing: yum --enablerepo=updates-testing update gnome-desktop control-center Works fine here with 2560x1024 wallpaper. The spanned option shows across two 1280x1024 monitors correctly. There is no need to use gconftool to set the setting either once you update correctly.
ahhhhhh.. It's back :) Note that the gconf schema should probably be updated (in the libgnome package)
oh.. and you also need to pull in nautilus from updates-testing as well.. otherwise if you have nautilus controlling the desktop it will "Revert" to old behavior.
OK, this finally works for me - you don't need to login and log back out again, but you do have to grab not only an updated gnome-desktop, but also control-center and nautilus. $ sudo yum --enablerepo=updates-testing update gnome-desktop control-center nautilus $ killall nautilus $ rpm -q gnome-desktop control-center nautilus gnome-desktop-2.28.2-5.fc12.x86_64 control-center-2.28.1-18.fc12.x86_64 nautilus-2.28.4-2.fc12.x86_64
Mind you, it turns out this still isn't the old (desired) behaviour. The code is still doing scaling and centering of the wallpaper across all screens. This is relevant because my second screen is only sometimes connected to my laptop. I now have a correct display when both are plugged in, but when I unplug the second screen, the entire wallpaper gets scaled to fit and centered on the first screen. We should not be scaling, nor centering a spanned wallpaper, just trust in the user to be doing the right thing.
Why was this update unpushed? The span option provided a feasible alternative that worked for what it was worth. I haven't seen any new activity in koji or bodhi since it was unpushed.
Because there is newer updates in -testing, and it was causing bodhi some problems.
(In reply to comment #36) > Because there is newer updates in -testing Where? repoquery --enablerepo=updates-testing -q gnome-desktop gnome-desktop-0:2.28.2-4.fc12.i686 gnome-desktop-0:2.28.2-4.fc12.x86_64
Woh, sorry. Looks like I killed the f12 update instead of the f13 one...
Appearance Preferences now has a "Span" option that works wonderfully.
Since gnome-desktop-2.28.2-5.fc12 has hit stable, should this bug be closed?
It's been working for me, so I would be fine if it were closed.
Agreed.
I saw the fix is also in F13. Thanks.