GNOME Bugzilla – Bug 147808
Background on dual monitors
Last modified: 2010-02-28 21:52:44 UTC
I am using 2 monitors, with a nvidia 5200FX card (dual vga), and would like to see in the future, be it gnome 2.8 or later. If there can be an option to set the background on one monitor. At current its kinda bad to have to expand 2 pictures to 1600x1200 (insert your resolution here), and place it by another picure, to make a 3200x1200 image. It would be hott, if each monitor can have an option to fill screen on that monitor and not across the entire resolution. :)
This is what the "Tile" option is for. For "scale/etc..." to work properly, this would probably be a feature request in Nautilus or gnome-settings-daemon. I'm not sure if there is code to special-case multihead like you want, in either of them.
Ok, Well if i have a 800x600 picture and i want to full-screen it, i dont want it to stretch over my 3200x1600 resolution, i just want it to full-screen on a monitor at 1600x1200. "Tile" would also tile that 800x600 over the entire 3200x1200 and not just on one monitor.
Hrm. If you're putting different pictures on different heads, I'd expect that option to be explicit in the UI rather than having to use a "Tile" option to achieve the effect. Even if that's what it does backstage. Related in many ways to bug 48004.
The request isn't for different pictures. It's to make the handling of multiple monitors in libbackground less stupid, I think. The point I was making with using Tile was that for a 1600x1200 picture, tiled across two 1600x1200 displays, effectively gives what you want. However, this won't work with multiple displays of different resolutions, or images that aren't the same size as the display. It will tile, but it won't have the effect requested in this bug. Unfortunately, I don't have multihead set up anywhere, and I don't know the libbackground code all too well. However, this is certainly an enhancement, and a low priority one.
Yea, I dont complain its simple to whip open gimp, copy image expand to my resoultion, and then tile it to place it on both, or get 2 images 1600x1200 and slap them on a 3200x1200 image, and use it. I do look for things that makes the UI simpler for a new user to gnome/linux. I wish i knew the libbackground code better myself for I would attempt to patch it. But yes this is not a "omy god im switching back to windows" problem...nothing is ever that bad ;)
Here's the thing - tile's behaviour is correct: take the existing image, don't alter it's size or aspect, and tile it. As it crosses the monitor boundary (which it doesn't need to know about) no problem. However, it is "centered", "fill screen" and "scaled" which end up looking stupid. Especially centered - you end up with an image half on one screen, half on the other, with a stupid black background (vertical, but reminicent of widescreen movies - expcept that widescreen movies don't have a big ass plastic and air gap down the middle of the picture!) My recommendation is that centered, fill screen, and scaled (or, at least some subset of them) be altered to be XINERAMA aware - as metacity was not too long ago with regards to maximizing windows - and only stretch/spread/whatever the image across an individual display screen, replicating (tile code subtly I would guess, but maybe not - up to XINERAMA) the same thing on the other heads. [right now my workaround is to take an image, manually scale it to a single monitor's resolution size (say, 1280x1024) then make it the background in tiled mode. Such a pain in the ass & waste of time. Gnome is so often better about these things] AfC Sydney
*** Bug 167177 has been marked as a duplicate of this bug. ***
*** Bug 323169 has been marked as a duplicate of this bug. ***
Ok it's been a long time since anything has been done here. Has this enhancement been worked on, or nearing completion? I am currently running 2.13.91 (or whatevers in CVS HEAD) and still don't see this feature.
*** Bug 334359 has been marked as a duplicate of this bug. ***
Is any work planned on this? It would be nice to have this fixed as Gnome is one of the few remaining major desktops which can't deal with desktop backgrounds for a dual-head setup in a sane manner.
Any work on this ? - Not being able to configure wallpapers separately when using two different sized screens is really a pain also XFCE and KDE has this working now.
I don't know if any further work is being done on this. I am now using 2.15.3 and still see no improvement on this bug. It is still a pain, now moreso that the other major Desktop Environments do have this working very well. I hope this will be working in 2.16.0
(In reply to comment #6) > My recommendation is that centered, fill screen, and scaled (or, at least some > subset of them) be altered to be XINERAMA aware - as metacity was not too long > ago with regards to maximizing windows - and only stretch/spread/whatever the > image across an individual display screen, replicating (tile code subtly I would > guess, but maybe not - up to XINERAMA) the same thing on the other heads. Even better than this would be if it was smart about whether to put the background across all screens, or each one individually. Simply scaling to each screen will break dual-screen-sized wallpapers (and similarly for the other non-tiled modes). My idea here is we should compare the aspect ratio of the wallpaper to a) the average of the screen aspect ratios, and b) the aspect ratio of the combined screens. If the wallpapers AR is closer to (a) then scale and display per-screen, and if closer to (b) scale across all screens. Take for example my dual 4:3 screen setup. A 4:3 wallpaper will get done per-screen because the average (4:3) is closer to the original (4:3) than the combined (8:3) is, and a 8:3 wallpaper would work similarly. A widescreen (16:9) wallpaper would turn out like this: per-screen-distortion = (4/3) / (16/9) = 0.75 combined-screen-distortion = (8/3) / (16/9) = 1.5 If we take the reciprocal of the former (to get it > 1), we see that the former (1.33) is less than the latter, so it would display the widescreen wallpaper per-screen. I don't really know the code for the background capplet, but from a quick look in applier.c: "if (prefs->wallpaper_type == WPTYPE_STRETCHED || prefs->wallpaper_type == WPTYPE_SCALED)" in refresh_render() needs to be "&& single_xinerama_screen", as we want the pixmap unscaled if we need to do it per-monitor. In run_render_pipeline() we need to determine whether to make the wallpaper per-screen. If so, and we aren't tiling, the code from setting the geometry up to and including render_wallpaper() needs to be done per-screen, with the appropriate screen-specific geometry settings. If not, we'll need to do the scaling removed above. It's probably harder than I think though.
i've got to admit this is a huge issue for me, and probably the only reason i use KDE in preference to KDE. In KDE it's really simple, i can choose a wallpaper (or list of wallpapers) and say 'on both screens' or 'on each screen' (and i think there's one for accross bot h screens as well). I've been reading some gnome terminology and discussions, and i believe the problem is fairly core. Everywhere it's a 'desktop background'. What we're asking for is a 'viewport background'. I'm planning on installing gnome and getting more familiar with it's code base. In fairness to you guys, windows doesn't handle this either. The older display managers do, kde does, and everyone else that i've seen doesn't. By making the background able to be configured per viewport, that would mean that if one of my images being randomly cycled in happens to be 1200x1024, and the other is 1600x1200, they'd get handled and loaded separately. It's conceptually very neat. I'd really love to see this in gnome.
(In reply to comment #15) > i've got to admit this is a huge issue for me, and probably the only reason i > use KDE in preference to KDE. *cough* KDE in preference to Gnome even :| sorry bout the typo.
I would like to add to Paul Harris' comment. It might seem like no big deal, but being able to manage wallpapers with a multi-headed display is a big issue for myself as well. When I find a background that I like, I don't want to have to open up an image manipulation package in order to get it to work right. As well, what happens if you have the secondary display temporarily disabled? I have a laptop and at work I use a second VGA display. When I use my laptop at home I only use the built-in display. If I had my wallpaper setup to support my dual-headed config, it would look messed up as soon as I went to a single display configuration. I find my self continually switching back to KDE for this functionality. KDE supports a multi-headed display configuration very nicely, but gnome seems to be stuck on one big display to rule them all. :(
*bump* welcome to almost two and a half years. Is there any work being done on this. I am currently getting from CVS and still don't see the change. It's quickly becoming one of the situations where I wish I spent the time learning how XINERAMA / libbackground work so I can try to patch it. If there are any updates please inform, otherwise I may just start hacking away at a solution, better start learning C I guess. -- dave
The problem is that there is no one single way to do it. Some people want one big desktop. Some people want arbitrary additional screens with arbitrary resolutions, etc... There's really no easy way to do a simple UI for it that I can immediately think of. And nobody has proposed any.
if (bigdesktop) { // way 1 } else { // way 2 } I guess it can be done the way apple does it, since I really like it. Display on each screen the preference for that screen. So you can set a resolution per screen. Granted this may add a couple lines to Section "Screen" Subsection "Display" ... in the x config. (or however that's handled) -- dave
It looks like something quite straight-forward, which was also reported downstream: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175810
Here's one more aspect of it. Recently, the intel video driver has learned to add and remove heads while X is running, with RandR 1.2 controlling what's going on. This is tremendously useful, and horribly breaks the "just gimp two images together" in most cases, as there's no guarantee that, say, the top-left screen is always the one with 1024x768 solution. Please make this happen.
(In reply to comment #19) > The problem is that there is no one single way to do it. Some people want one > big desktop. Some people want arbitrary additional screens with arbitrary > resolutions, etc... There's really no easy way to do a simple UI for it that I > can immediately think of. And nobody has proposed any. > ?? other desktop environments can do it I've been using gnome as my main desktop, coming from KDE I find gnome a pain period to customize and no ability to display 2 different wallpapers is horrible. Dual monitor setups is very very popular and this should seriously be developed.
i dont see why this cant just be another configuration object. Why cant we have a list of images (just one list would be fine) and allow the system to randomly choose an image for each monitor out of that list of images? I really dont see why this is such a problem... Things like this come down to configuration.... we're talking about an extra checkbox as far as the user is concerned, and some logic in the back to drive it.
If it isn't already obviously to people asking whether anyone is working on this bug, the answer is no. This doesn't mean that no one thinks it's an important feature. It just means no developer has thought it interesting enough, or perhaps doesn't have the hardware to test it in order to write a patch. If anyone is willing to write a patch that integrates nicely into the new appearance capplet, I'm sure it would be considered for inclusion.
(In reply to comment #19) > The problem is that there is no one single way to do it. Some people want one > big desktop. Some people want arbitrary additional screens with arbitrary > resolutions, etc... There's really no easy way to do a simple UI for it that I > can immediately think of. And nobody has proposed any. > I'm sorry, I thought my mention of 'kde can do it' may be enough information on a possible implementation, but since it's clearly not i'll try to describe it as best i can. When i go into the 'Change background settings' screen, I have a UI that presents me with all my options... Settings for desktop: (PDL of 'All Desktops', 'Desktop 1'..'Desktop N') (PDL: Accross all screens , On Each Screen, Screen 1 ... Screen N) Background group: bullet list of (No picture, Picture (with a select to point at the file), Slide show (with a setup button which takes you to a setup screen)) Options group: position / scale etc.
Created attachment 97501 [details] configuring kde desktop background
Created attachment 97502 [details] the slideshow window for kde
GAH sorry about post 26 - it really didn't do what i wanted... so start with my attachments for what that was *trying* to describe. Now for the simplicity of it. I'm lazy, so all i want to do is set up my background for 'all desktops', but i want to have separate images on both screens, so i set up my settings as shown in the screeenshot of the background settings i attached. If i want to, i can decide i want to setup desktop 2 differently. I could also setup a separate slideshow for each monitor if i so desire. If i switch from what my current settings are to make 'on each screen' => 'Screen N' the settings are consistent with what i set up under 'each screen'. If i switch to 'Accross all screens', that's something that's unconfigured so i get a default page to start setting it all up. If i switch to screen 2 I can then go in and setup whatever i want to display on that screen - a slideshow, static picture, single color etc - all associated to that screen (in this case still on all desktops). If i want to, i can setup each screen on each desktop differently, but see the comment about me being lazy. I find this configuration highly intuitive. The simplicity from a UI perspective is very nice. Because the UI just duplicates your settings to each screen or each desktop, you're effectively making the back end not have to think too much, as all the settings would be denormalised. The two PDLs at the top of the configuration page really drive all the configuration power of the dialog. When they change, all the information is loaded for the appropriate selection. As with screens, if i go and change my 'all desktops' to 'Desktop N' i have the same settings that i had under 'All Desktops', so the 'All Desktops' and 'On each screen' are just used to direct the save process to save the selection to all the desktops / screens From my darkest memories, the 'Across all screens' is the default when you initially install. This is fair enough, as it's what people are used to. I haven't actually *read* the code of the KDE desktop background settings, but the above is my understanding from a user perspective of how it's working. Hopefully this adequately answers the question of 'how it might be done', but i'm more than happy to discuss this further as i'm keen on seeing this in gnome so i can start using it :)
*** Bug 501471 has been marked as a duplicate of this bug. ***
*** Bug 503435 has been marked as a duplicate of this bug. ***
Eww, happy 3rd birthday! I came from bug #503435, it just seemed to me like an issue of mathematics, a typo in the code that nobody had noticed; it looks like quite a lot of people actually are affected by this. I initially thought, "well, for scale modes just calculate the dimensions of each individual screen and there we go... No further user interaction required". What is actually holding off this bug? Design debates or lack of progammer time? (sadly I cannot code myself, heh)
So far noone has decided it's important enough to fix (so i'll just keep using kde *nudge nudge*) It'd take me too long to figure it all out to do it myself... Maybe one day when i've got a lot of time on my hands I could take a look and see what's going on, but for now I'm hoping the community will see fit to fix this issue. As time goes on and multi-head displays become more common, this problem is likely to be more apparent to more people, and then with any luck we'll see some resources committed in this area. Until then, we're just going to have to live with it :|
I'm going to take a bash at fixing this. Sounds like nobody in gnome world finds this interesting enough to bother; there being bigger fish to fry. However, though I'm a C coder by trade, but nothing I write ever has a UI, so I'm a little bit like a fish out of water wading through the gnome code, so I'm not promising a patch in under a week here ;) That said, I've got a working development environment and have dabbled somewhat with the GTK+ stuff. Can someone point me to what I'm likely to need to modify to get this working? I'm going to make some guesses here, I don't really understand how gnome does stuff yet though I've checked the code out and had a look. Here is my proposal on solving the issue for people like me and David. It should also not break existing functionality for people who like to just tile the same image across screens (Which rarely works for me without resizing the images to be the same size as the screen, which they never are). 1. New keys in gconf are required to support a different wallpaper image for each display. There should be a key to set to enable the new behaviour, by default if this key does not exist/is unset the current behaviour should be used. Keys (not sure how they're specified in gconf, I have to work this out ;) Enable multiple wallpaper support (boolean) screen 0 wallpaper path screen 0 wallpaper style screen 0 wallpaper color screen 1 wallpaper path etc... 2. The code that actually displays the wallpaper in the root window to handle these extra keys and display the correct wallpaper on each display. (is this applier.c? at work, so I can't check.) 3. Once the support has been added in the display part, modify the appearence UI to configure it. On single display systems, there should be no change to the way this panel behaves or looks, other than the addition of a greyed out drop down list. 4. The Background tab in the Appearance Preferences needs an additional UI element: a dropdown list that allows the user to select what screen they are modifying the settings for. Options like style and color should be configurable per screen. 5. New code to detect the current number screens and their geometry needs to be added to the capplet so that it can populate the list correctly. 6. An additional style should be added (only on multi-head systems), which should grey-out the display drop down list, called "mirrored". This should set the same wallpaper/color on both screens. Do people feel this is an appropriate way of approaching the problem? As someone new to the code base, is there anything I need to read that would help me get up to speed? Thanks.
OK, its not that easy. The code that handles the gconf changes when you change it in the capplet is in nautilus-directory-background.c and in eel-background.c (in eel). libbackground just seems to handle the reading/writing of the gconf data and while it will need to be modified to handle multi head, its not the majority of the work. To make this work, I need to make eel multihead aware, and add the extra gconf keys. Nautilus also needs to be aware of these keys, as does libbackground. And finally, so does the capplet :) So, small itch, great amount of pain. I'm beginning to understand why nobody has been enthusiastic about fixing this. The current keys are: /desktop/gnome/background/picture_options /desktop/gnome/background/picture_filename /desktop/gnome/background/picture_opacity /desktop/gnome/background/primary_color /desktop/gnome/background/secondary_color /desktop/gnome/background/color_shading_type I propose adding the following keys: /desktop/gnome/background/multihead /desktop/gnome/background/screen1/picture_options /desktop/gnome/background/screen1/picture_filename /desktop/gnome/background/screen1/picture_opacity /desktop/gnome/background/screen1/primary_color /desktop/gnome/background/screen1/secondary_color /desktop/gnome/background/screen1/color_shading_type So, now the messy part. Twinview and Xinarama make a large rectangle, with the screens fitted into that rectangle. If you have two screens sized the same, there is no dead space. Two or more screens of different sizes, or in odd configurations (one screen above with one on either side, etc) causes dead space to be created offscreen. Window managers are usually clever enough to not let you move your window title bars/mice offscreen, but the area exists. So, the code needs to detect, somehow, the screen geometry and create one very large wallpaper in memory that scales each image for each screen into the right place so that it is viewed correctly. Whats more, if you select scaled for two images, one image should not clip onto the screen of the other image. Additionally, there is the case where a user may have true multi-head configured, where each screen is a separate X Server and windows may not be dragged across. This case is easier to cater for because it is pretty much the same as what we have now, we just need eel to recognise "this is screen :1, so, use the /screen1/ gconf keys". So this is non-trivial, mostly because X has so many possible configurations, and the way X handles the root window. But hey, I'm willing to take a shot, depending on whether or not there is a sensible way to implement this that will be accepted by gnome. Obviously there is no point hacking on it if the planned workaround is unacceptable.
(In reply to comment #36) > The code that handles the gconf changes when you change it in the capplet is in > nautilus-directory-background.c and in eel-background.c (in eel). libbackground > just seems to handle the reading/writing of the gconf data and while it will > need to be modified to handle multi head, its not the majority of the work. Some of it is also in gnome-desktop (gnome-bg) and gnome-settings-daemon (plugins/background, because g-s-d can take over when nautilus isn't managing the background)... (Although, to be fair, they do share *some* code.) > So, small itch, great amount of pain. I'm > beginning to understand why nobody has been enthusiastic about fixing this. Yes! > I propose adding the following keys: > /desktop/gnome/background/multihead > /desktop/gnome/background/screen1/picture_options The typical scheme is to just number the gconf directories, so /desktop/gnome/background/1/... I'd also scrap the "picture_" prefix. > /desktop/gnome/background/screen1/picture_filename While you're at it, change that to ..._uri. Filenames are evil, in arbitrary encodings and can't really be properly stored in gconf anyway. Use escaped URIs instead. > Twinview and Xinarama make a large rectangle... I'm not sure loooking at Xinerama and TwinView is a good idea. TwinView is proprietory technology anyway, and Xinerama is on its way out in favour of XRandR. > Additionally, there is the case where a user may have true multi-head > configured, where each screen is a separate X Server and windows may not be > dragged across. This case is easier to cater for because it is pretty much the > same as what we have now, we just need eel to recognise "this is screen :1, so, > use the /screen1/ gconf keys". I'm not completely sure, but ideally, this complexity would go away (to some extent) with xrandr 1.2. > But hey, I'm willing to take a shot, depending on whether or not there is a > sensible way to implement this that will be accepted by gnome. Obviously there > is no point hacking on it if the planned workaround is unacceptable. "Workaround" sounds pretty bad to start with. A properly designed, working solution would certainly be acceptable. If you set out to tackle this you should also make sure that with your design it's possible to add support for setting individual wallpapers *per workspace* later on without completely redoing everything *again*.
Hi Jens, thanks for your comment. > Some of it is also in gnome-desktop (gnome-bg) and gnome-settings-daemon > (plugins/background, because g-s-d can take over when nautilus isn't managing > the background)... (Although, to be fair, they do share *some* code.) A lot of magic seems to happen in gsd-background-manager.c, at least to handle the case when Nautilus is not running or not managing the root window. It already gets the number of screens, iterates through them and places a pixmap as the root for each, so hooking the support for this there should be fairly trivial. If we set /apps/nautilus/preferences/show_desktop to false, does Nautilus still draw the icons and such? Is this just for the wallpaper? If so, we could do what we need to do in gsd-background-manager.c. Otherwise we'll need to share the code in both eel and gsd-background-manager.c .. right? I'm still a bit hazy on where we need to implement this. I don't think Nautilus cares/understands what a screen is, where gsd-background-manager does. > The typical scheme is to just number the gconf directories, so > /desktop/gnome/background/1/... > I'd also scrap the "picture_" prefix. Sounds good. Though I didn't want to break people's current settings. :) /desktop/gnome/background/multihead /desktop/gnome/background/1/options /desktop/gnome/background/1/uri /desktop/gnome/background/1/opacity /desktop/gnome/background/1/primary_color /desktop/gnome/background/1/secondary_color /desktop/gnome/background/1/color_shading_type I'm not sure that just /options, /uri, /opacity, etc is clear enough. > I'm not sure loooking at Xinerama and TwinView is a good idea. TwinView is > proprietory technology anyway, and Xinerama is on its way out in favour of > XRandR. Well. I mention Twinview because thats what I use, and this being a personal itch I want to scratch it in a way that works for me; I'm kind of stuck with nvidia's proprietary driver if I want good OpenGL performance (which I do). No doubt many are in the same boat. But you are correct; XRandR is the correct way to handle multiple displays, and anything I implement should support what the standard going forward will be. Nobody wants to come back and redo all of this later on, so doing it right this time around is important. XRandR is not supported in the current nvidia proprietary driver, but it will be 'real soon now'. One could reasonably expect that it will be delivered this year. Might not be worth looking at Twinview and Xinerama with that in mind. > I'm not completely sure, but ideally, this complexity would go away (to some > extent) with xrandr 1.2. I think you're right. > "Workaround" sounds pretty bad to start with. A properly designed, working > solution would certainly be acceptable. If you set out to tackle this you I'm setting my own expectations here, really ;) > should also make sure that with your design it's possible to add support for > setting individual wallpapers *per workspace* later on without completely > redoing everything *again*. Compiz might complicate this. They'll need to handle it so they can render the correct background on each face of the spinning cube, for instance. The keys would be right there in gconf, though, so it should be fairly easy for them to deal with it. With your comments I'm closer to a solution for doing this but it's still pretty vague. If its possible to get Nautilus to not 'own' the root window, and not care about wallpapers, but rather have gsd own it, and manage it, then maybe this stuff gets a little easier. I'm going to need to do a lot more research though, and trying to do different wallpapers for each workspace will complicate things when you mix in things like compiz. I suspect I'll have many questions as I work on this, and should probably take it to a mailing list. What place is appropriate to take this discussion?
My understanding is that Xinerma, TwinView and XRandR all export the same Xinerama hints: how many monitors you have, and where each one is located in the viewport. Gdk exports that information via gdk_screen_get_n_monitors and gdk_screen_get_monitor_geometry functions. (Don't confuse screens and monitors -- multiple screens in X are what you get when you don't use Xinerama; each screen gets a separate gdm login screen and a separate desktop session.) For extra fun don't forget the case where you have a "clone" mode with different monitor sizes -- i.e. the rectangles returned by gdk_screen_get_monitor_geometry overlap. E.g. my laptop has a 1280x800 LCD, and if I try to use a dual-head clone mode with a 1280x1024 monitor, I get two views to the same 1280x1024 desktop, one of which shows only the upper portion. I think the sanest thing to do in this case is to draw just one wallpaper on the larger rectangle. My understanding is that Nautilus needs to own the root window because Nautilus draws the icons on the desktop. Perhaps when you have a composition manager you could get away with Nautilus drawing a transparent ARGB window on top of the desktop drawn by g-s-d... Disclaimer: I'm not a GNOME hacker. I'm just a user interested with delusions of knowledge.
(In reply to comment #38) > If we set /apps/nautilus/preferences/show_desktop to false, does Nautilus still > draw the icons and such? Is this just for the wallpaper? If so, we could do > what we need to do in gsd-background-manager.c. Otherwise we'll need to share > the code in both eel and gsd-background-manager.c .. right? When nautilus is managing the desktop it's managing all of it (background + icons). So yes, the code needs to be shared. I haven't looked at the background stuff in gnome-desktop, but that might be the place for the shared parts. > Sounds good. Though I didn't want to break people's current settings. :) We probably need some migration code to move the old gconf entries to the new format. That's not something I'd worry about now, though. > I'm not sure that just /options, /uri, /opacity, etc is clear enough. They're fine when you look at the entire path. > Compiz might complicate this. They'll need to handle it so they can render the > correct background on each face of the spinning cube, for instance. I'm not using compiz, nor have I looked at what it does code-wise, but I'd be somewhat surprised if that needed special-casing. I must admit I'm not quite sure at which level workspaces are defined conceptually. X? Window manager? If the latter, this would need WM support to implement obviously. > I'm going to need to do a lot more research though, > and trying to do different wallpapers for each workspace will complicate things > when you mix in things like compiz. It doesn't have to be implemented right away. But the solution should be designed in such a way that it's not impossible to do so. > I suspect I'll have many questions as I work on this, and should probably take > it to a mailing list. What place is appropriate to take this discussion? gnomecc-list
I had a good look .. but I'm not comfortable tackling this. Its just so many parts that need to be touched. I think when XRandR is supported on all drivers (including the proprietary ones) this won't be so hard to fix, but right now XRandR is only partially supported on my card, so its hard for me to test sanely. Sorry guys. I did try :) At least I have a better appreciation for why this bug has been left for so long.
Nathan, thanks so much for your effort! It was interesting, and hope filling!, to see the comments on this thread over the last week or so, suddenly awoken from its inactivity. So, uh, since it's a huge pain in the ass to do it the right way, and I mean, a /huge/ pain in the ass, what is the likelihood that we could slip in a patch that fakes it? Barring weird edge cases, I think that the majority, Xinerama enabled two-to-three-screen, rest of us wouldn't complain if we automated the "stitching background together" workaround in a simple gui, and we can tell the poor saps who want background-per-virtual-desktop to go WONTFIX themselves for four years ;). I haven't time or inclination to do this myself, at the very least until the middle of the summer, but right now it sounds like the most pragmatic alternative. I certainly wouldn't spend two weeks fixing it, tho.
Created attachment 108356 [details] *Very* simplistic Python stitching program Here's a *very* simplistic Python stitching program that is specific to my setup, but easy to customize even if you don't know Python. Use as compose-dual screen1.jpg screen2.jpg out.jpg Note: this does not even *pretend* to be user-friendly, but it might serve as a starting point onto which one might slap a GUI for an interim solution.
Created attachment 108386 [details] Less simplistic Python program Here's a less simplistic Python script that'll a) ask xrandr about screens b) pop up file pickers (with previews) asking for wallpapers for each screen c) ask for a name to save under d) set the desktop background to that file It uses GdkPixbuf to achieve its magic, so as long as you have the Gnome Python bindings installed, you're golden. I hate being a mathematician. I can't leave anything at a half-ass solution. :/
*** Bug 341529 has been marked as a duplicate of this bug. ***
gnome-desktop contains the relevant background stuff. The root cause is that gnome-desktop accepts whatever X11 says the resolution is, and X11 considers any number of monitors to be a single virtual monitor. Any GdkScreen you come across will reflect this flawed assumption. This is probably not correct. Fixing it would be a relatively far-reaching change, and I would be hesitant to make it. The alternative is to make the change only in regard to desktop backgrounds, similar to how Metacity fixed its multiple monitor issues. This is also rather ugly. An alternative is to expose GdkScreenX11's monitors property in a more general way and use that where appropriate. This preserves current behavior while abstracting away Xinerama calls or the like. Metacity's window placement code may be a good place to start looking for examples for using Xinerama for retrieving screen information: metacity/src/core/place.c.
Gtk already has an api for getting monitor layout (from xrandr, falling back to xinerama). See: gdk_screen_get_n_monitors() and gdk_screen_get_monitor_geoemetry() A screen in the X sense isn't necessarily tied into one monitor. It's a big virtual screen that each monitor is a sort of viewport into. Monitors can even overlap (show the same part of the virtual screen). That's how clone mode is implemented for instance. Getting the monitor layout information isn't hard, the hard part is figuring out what to do with it. Normally the background is drawn in one of two places: - the root window (if nautilus isn't running) - the nautilus background window (if nautilus is running) Both of the windows span all monitors. If you want to draw a background per monitor then you probably need to 1) analyze the monitor layout, finding the biggest monitors in the list that don't overlap and disregard small monitors that do overlap those bigger monitors. 2) assign a background to each monitor that hasn't been pruned 3) stitch together the assigned backgrounds (as mentioned by Andreas earlier) Use this stitched composite image on the root window / nautilus background window. In theory you could do slightly better in the nautilus is running case: have separate background windows per monitor head. That would mean smaller texture size requirements. Also there has to be some way for the background capplet to assign a background to a particular monitor. Should it set the background the user picks to the monitor the background capplet is running on? Should use the same background for every monitor always? Anyway, fixing this bug is certainly doable, but just a little complicated and no one has sat down to do it yet.
Would anyone complain if, as an intermediate step, we have the same settings, but optionally applied per monitor? This would emulate the behavior of Windows; for example, if you selected an image and set it to Fill, it would fill each monitor separately (scaling appropriately if they are different sizes). Likewise, Center would display the image centered on each monitor. This change is relatively simple.
I'd be very happy with that as an intermediate step... in fact that would probably be the only step i needed... Currently i've worked around the problem with a perl script that just rotates my background with the rules i want, but it's literally just 1 set of rules (1 set of images, 1 timed rotation, fixed orientation) that it applies, which is effectively this intermediate step :)
Created attachment 139129 [details] [review] Draws non-tiled backgrounds separately for each monitor I hacked up a version, but it's hard-coded for split monitors (i.e. you won't be able to use that nifty dual-monitor background). Working on configurability. In the interim, here's the hard-coded version (applying it against 2.26.1 was a drop-in replacement for ubuntu).
Please create patches like this against trunk, not 2.26 if they are supposed to be applied upstream.
I created the patch against trunk. It works with 2.26 as well. I apologize for the confusion.
Nice! This change is exactly what I was looking for: the same wallpaper drawn on each monitor independently so it doesn't get chopped up like it currently does. This is how Windows does it. I can't really reason for this other than that it specifically applies to my situation of a laptop with a distant external monitor always being plugged and unplugged. Plugging in the large external monitor which sits at the opposite side of the room should not mean the wallpaper gets chopped in half such that my laptop only sees the top left-hand corner. Although understandably if someone has four monitors of equal pixel height lined up on their desk they may want a single wallpaper spread across them. Is there a chance of getting this in 2.30? In fact, could someone give me instructions on compiling this into a .deb for Ubuntu Karmic? Thanks!
Review of attachment 139129 [details] [review]: I'm not the maintainer but I thought I'd try to help out. I like the idea of this a lot. When trying this out I noticed that we'll need to also change: * the appearance capplet to not ask for thumbnails at the size of the screen * nautilus (eel-background) to not request an image the size of the screen because this confused the code that tries to find the best image size in a size-only slideshow ::: libgnome-desktop/gnome-bg.c @@ +39,3 @@ #include <X11/Xatom.h> +#include <gdk/gdkdrawable.h> Shouldn't need this. And it isn't allowed to include anything but gdk.h anymore. @@ +690,3 @@ + GdkPixbuf *pixbuf, + GdkPixbuf *dest, + GdkRectangle *region) This should still be static, no? @@ +711,3 @@ case GNOME_BG_PLACEMENT_FILL_SCREEN: case GNOME_BG_PLACEMENT_SCALED: + pixbuf_blend (scaled, dest, 0, , w, h, x + region->x, y + region->y, 1.0); Missing a number here. @@ +735,3 @@ + rect.width = dest_width; + rect.height = dest_height; + Might be a little nicer without the local variables dest_*. @@ +741,3 @@ +void +draw_on_monitor (GnomeBG* bg, GdkPixbuf *dest, GdkRectangle *region) +{ GnomeBG *bg @@ +752,3 @@ + int monitor; + + // tile: don't worry about aligning on every monitor Not a huge deal but I wouldn't start using C99 comments if they aren't already used. @@ +763,3 @@ + } +} + Shouldn't this be an if/else? Doesn't this draw twice for TILED? @@ +779,1 @@ } What is this for?
I've bought a second monitor recently and unfortunately it's impossible to set different wallpapers without creating a new image. XFCE and KDE4 do it well but I don't want to change my desktop environment just to set wallpapers, but I think this is a great improvement to look & feel and I can't wait to see this working in Gnome. Does this patch work on Gnome 2.28?
Created attachment 147224 [details] [review] gnome-desktop patch Sorry about the duplicate review above. There is a bug in splinter. Here's an updated patch that fixes the things I pointed out. It also fixes the case where get_pixbuf is caching the wrong size images from slideshows. It defaults to caching the primary monitor size now instead of the screen size. At some point we may want to add logic to make it have a cached image per aspect ratio or something but I don't see that as critical. I'll also attach patches for nautilus and control-center.
Created attachment 147225 [details] [review] patch for control-center This fixes the appearance preferences to use the aspect ratio for the primary monitor instead of the screen.
Created attachment 147226 [details] [review] patch for eel This makes eel-background trigger a redraw when monitor configuration changes. This is necessary so that we reblend the per-monitor images onto the root pixmap in the proper locations.
void gnome_bg_draw (GnomeBG *bg, - GdkPixbuf *dest); + GdkPixbuf *dest, + GdkScreen *screen); This seems like an unnecessary api change, considering that other code in there seems to happily use the default screen. Also, as Jon points out on irc, this api seems entirely unused...
The eel patch is technically a nautilus patch, nowadays, since eel as a standalone entity is no more.
Wow, I applied the patches, and I can't begin to say how enthralled I am that I can have a background full-screen on both desktops. After 5+ years something is starting to happen! Bonus kudos to everyone for getting started on this.
Hey, great work! Is there any way to recommend this to be included in official source code?
Review of attachment 147224 [details] [review]: No deep review here, just some cosmetic things... ::: libgnome-desktop/gnome-bg.c @@ +690,2 @@ static void +draw_image_region (GnomeBGPlacement placement, It's weird to call the function draw_image_region when it doesn't take a GdkRegion. I'd call it draw_image_area or draw_image_rectangle @@ +739,3 @@ + +static void +draw_on_monitor (GnomeBG *bg, GdkPixbuf *dest, GdkRectangle *region) again, not a fan of the name. This function doesn't actually draw on a monitor does it? Maybe call this draw_background_subimage_for_area ? Alternatively, move the get_monitor_geometry call here, and call it draw_background_subimage_for_monitor @@ +745,3 @@ + +static void +draw_each_monitor (GnomeBG *bg, GdkPixbuf *dest, GdkScreen *screen) I'm not 100% sure of the gnome-desktop style, but I think these parameters need to be on their own line. @@ +2007,3 @@ + return pixbuf; +} + My first thought when I see this function is it feels a little like duct tape. I could see having it as a compat interface if we cared about api stability and it wasn't a static function, but since it is a static function it's a little weird. I think it would be better to drop this function entirely and rework the callers to use more explicit interfaces for what they want. It definitely feels like there should be a bg_failed_to_load boolean, function or something to replace all the get_pixbuf (bg) == NULL checks.
Review of attachment 147225 [details] [review]: ::: capplets/appearance/gnome-wp-item.c @@ +216,3 @@ + + /* Use primary monitor for aspect. Should we use the monitor with + the pointer? */ Maybe pass in the monitor screen and monitor the dialog is opened on?
Review of attachment 147226 [details] [review]: ::: eel/eel-background.c @@ +898,3 @@ + } + background->details->screen_monitors_handler = + g_signal_connect (screen, "monitors-changed", should probably be "monitors_changed" to match the surrounding signals.
Created attachment 149068 [details] [review] updated patch for gnome-desktop We still need to rework the g-c-c and nautilus patches to match. This update should fix the issues from Ray's review. It also changes the changes_with_size() function to be has_multiple_sizes() because that what it is supposed to be used for in g-c-c (but it currently doesn't work). The old function was also used by nautilus to try to optimize not redrawing backgrounds that are just a color or something but I think we should probably drop that part. We should also fix the caching to be per aspect ratio but at least that is feasible now that we've removed get_pixbuf().
Comment on attachment 149068 [details] [review] updated patch for gnome-desktop Oops. That call to get_pixbuf in gnome_bg_get_pixmap isn't right. I'll fix it up tomorrow.
Created attachment 149288 [details] [review] updated patch for gnome-desktop Updated patch. Fixed above problem and adds support for matching aspect ratios for the different monitors.
Created attachment 149290 [details] [review] updated patch for eel
Created attachment 149291 [details] [review] updated patch for g-c-c Now will display the thumbnails in the orientation of the monitor that the capplet opens on and will reorient the thumbnails when the monitor aspect ratio changes.
Review of attachment 149291 [details] [review]: Nice cleanup, too! ::: capplets/appearance/gnome-wp-item.c @@ +281,3 @@ */ + if (description && size) { + item->description = g_markup_printf_escaped (_("<b>%s</b>\n" This part needs the translators hint fixed/updated/moved.
Review of attachment 149291 [details] [review]: Changing from landscape to portrait should probably not grow the thumbnails but just rotate their dimensions. You seem to recompute the aspect ratio all the time. Other than that, looks fine.
Review of attachment 149288 [details] [review]: Looks fine to me in general. The only meta-comment I have is that it may finally be time to break down and admit that gnome-desktop has APIs that are used desktop-wide and are worth documenting. ::: libgnome-desktop/gnome-bg.c @@ +1946,3 @@ + width = gdk_pixbuf_get_width (bg->pixbuf_cache); + height = gdk_pixbuf_get_height (bg->pixbuf_cache); + hit_cache = 0.2 > fabs ((best_width / (double)best_height) - (width / (double)height)); As already commented in the hallway by Ray, it may be better to only allow exact aspect ratio matches, or figure out a way to see if there's a better aspect ratio match available without high cost.
Created attachment 149489 [details] [review] updated patch for g-c-c * Fix translator comment * Fix thumbnail size & recomputation
Review of attachment 149290 [details] [review]: Looks good to me.
Thanks Chris Wright and others. This is pushed to master.
Review of attachment 149290 [details] [review]: ::: eel/eel-background.c @@ +1010,3 @@ + /* only check for the background on the 0th monitor */ + screen = gdk_screen_get_default (); + gdk_screen_get_monitor_geometry (screen, 0, &rect); Why are you always using the monitor size here? Is this really the right thing for EelBackground objects for windows other than the desktop window?
Holy crap, after 5+ years it's nice to see the word 'Fixed' on this bug, however, I do have to question if it's actually "fixed". I see it working, as in the picture scales, and looks better on each screen however, I don't think that's finished the main part of this bug: "If there can be an option to set the background on one monitor. At current its kinda bad to have to expand 2 pictures to 1600x1200 (insert your resolution here), and place it by another picure, to make a 3200x1200 image." Seems as if this fix takes the image and displays it on each monitor so that it doesn't look stupid, but as to the distinct setting the background per-monitor, I don't see that yet. Not to complain about the work, it's fantastic to see people taking an active role in this!
(In reply to comment #78) > Review of attachment 149290 [details] [review]: > > ::: eel/eel-background.c > @@ +1010,3 @@ > + /* only check for the background on the 0th monitor */ > + screen = gdk_screen_get_default (); > + gdk_screen_get_monitor_geometry (screen, 0, &rect); > > Why are you always using the monitor size here? > Is this really the right thing for EelBackground objects for windows other than > the desktop window? is_dark() should only load an image if not already cached. The loading is done through get_as_pixbuf_for_size() which doesn't scale the image if the background placement is TILED. The idea here is that the passed in size should be the "requested size" of the source pixbuf. In the case of the desktop window this is the monitor size. In the case of other nautilus windows it is the size of the window. We can't use the window size for the former case because nautilus' window is not per monitor. I suppose we could still change that if we think it is worth it. One reason why the function needs to know the requested size is that it loads and caches the source image as a side effect. And would otherwise have to assume or guess a size. I was also able to verify that we don't scale up tiled images to the monitor size by adding some g_messages to is_dark() when called by nautilus using tiled backgrounds: ** Message: is-dark called ** Message: requesting pixbuf for 1680 x 1050 ** Message: got pixbuf of 64 x 64 There are still oddities in the gnome-bg api but I don't think we've broken it in any significant way here.
(In reply to comment #79) > Holy crap, after 5+ years it's nice to see the word 'Fixed' on this bug, > however, I do have to question if it's actually "fixed". I see it working, as > in the picture scales, and looks better on each screen however, I don't think > that's finished the main part of this bug: > > "If there can be an option to set the background on one monitor. At current > its kinda bad to have to expand 2 pictures to 1600x1200 (insert your resolution > here), and place it by another picure, to make a 3200x1200 image." > > Seems as if this fix takes the image and displays it on each monitor so that it > doesn't look stupid, but as to the distinct setting the background per-monitor, > I don't see that yet. > > Not to complain about the work, it's fantastic to see people taking an active > role in this! Hey man. I think we should close this and interpret the feature as "add per-monitor backgrounds". If you still want to be able to configure separate backgrounds per output then please clone this bug and state that part explicitly in the feature request. It is kinda messy and confusing to have two issues in one bug report and I think we can consider one part of this report to be fixed. Thanks.
Testing finds the following issues: A horizontal gradient goes over both screens rather than once over each screen. The same is probably happening on vertical gradients if monitors are stacked over each other. Center and zoom does not clip the drawing of each monitor to the part that is on that monitor, so the second drawn monitor bg overlaps the previously drawn first monitor.
(In reply to comment #82) > Testing finds the following issues: > > A horizontal gradient goes over both screens rather than once over each screen. > The same is probably happening on vertical gradients if monitors are stacked > over each other. > > Center and zoom does not clip the drawing of each monitor to the part that is > on that monitor, so the second drawn monitor bg overlaps the previously drawn > first monitor. These and other issues should be addressed by the patch I pushed on Friday.
Thanks to this "fix" (with the latest updates on Fedora 12 anyway) I can no longer set a background image that spans my dual monitors (twinview Nvidia setup). I'm really missing that functionality.. am I missing some means to set an image to span both monitors with this change? I tried everything I could think of with no luck.
Basically confirming Chris' comment here, I spent an hour searching why this suddenly broke my nice dual-monitor backgrounds. There's also a report on the Fedora forum here: http://forums.fedoraforum.org/showthread.php?p=1315448 Let me know if you want a new bug for this regression.
This bug was filed some time back: https://bugzilla.gnome.org/show_bug.cgi?id=603551 All dual monitor wallpapers are now broken because of this fix. I'd be really happy if someone has a workaround/fix for it.
I also just spent quite a while diagnosing the issue until I finally managed to track it all down to this bug. See: https://bugzilla.redhat.com/show_bug.cgi?id=556369 The status of this bug should be changed to 'RESOLVED BROKEN' ;-), ie. it should be reopened. As for a workaround... If you are running Fedora 12. Go to koji for gnome-desktop http://koji.fedoraproject.org/koji/buildinfo?buildID=146755 and fetch the package gnome-desktop-2.28.1-6.fc12.${ARCH}.rpm This is the last unbroken package. Then you can run: rpm -hvU <package location on disk> --oldpackage. If you then restart nautilus (for example: killall nautilus nautilus & bg or just plain restart X or logout and log back in), the issue should go away.
Seems the fix didnt work out for many(majority?) the way it should have. Now there is absolutely no way to set two different wallpapers on two different monitors. I hope the devs consider either pulling out the changes or enhancing them in some way to keep everyone happy.
This is terrible. My dual-screen wallpapers are all squished into one screen. Can this change be reverted? Please? :(
Created attachment 153483 [details] [review] 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 reply to comment #90) > Created an attachment (id=153483) [details] [review] > patch adding a "spanned" option for picture_options Hi, sounds like a good idea. However, since this bug is closed would you mind opening a new bug for this patch? Please link to the new bug from here so people can find it. Thanks!
Theres a bug already for this: https://bugzilla.gnome.org/show_bug.cgi?id=603551
Is bug #147808 really "fixed" if the fix creates a serious regression? Between this bug report and Fedora's bug #556369, at least 9 or 10 people have commented on this regression, and the original reporter (comment #79) doesn't seem convinced that this is fixed. Also, I think there are a few duplicate bug reports on the GNOME bugzilla about this problem. Bug #604301 seems to be about this problem, as is #603551. Anyway, where should I post this? And why hasn't the "fix" been unfixed in the meantime?
Okay. I've added the patch to bug #603551.
By the way, per-monitor-background.patch also seems to have created a big memory leak, which I have described at: https://bugzilla.redhat.com/show_bug.cgi?id=558596 Now that I'm using "spanned" mode, I am now longer experiencing a huge memory leak anymore.
Thanks folks. amcnabb, can you also file a GNOME bug for that? That sounds like something we need to fix right away. If you have any debugging info that would be very helpful too. Thanks.
I have done this as bug #609599. The bug is incredibly easy to reproduce (just change the background over and over).
FYI, I just updated https://bugzilla.redhat.com/show_bug.cgi?id=556369 to state that the current patch in Fedora 12 koji (which I assume is a patch from here) doesn't seem to fix the problem for me. 'spanned' seems to behave like centered (each screen has a separate wallpaper, the central part of the huge wallpaper, without any scaling, centered on screen).
Actually the latest patch DOES fix the issue.. you need to update gnome-desktop to version 2.28.2-5.fc12 and control-center to version 2.28.1-18.fc12 then completely log out and back in again. To easily update to those version w/o using koji just run this as root or under sudo yum --enablerepo=updates-testing update gnome-desktop control-center Then go into the appearance control panel and set the tiling style to "Span".
I did get the packages from the updates-testing repo. #rpm -qa | grep gnome-desktop gnome-desktop-2.28.2-5.fc12.i686 #rpm -qa | grep control-center control-center-2.28.1-18.fc12.i686 Still no luck. Weird... this working for some people and not for others.
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
Sorry if I didn't make that clear...indeed you need all 3 updates.