GNOME Bugzilla – Bug 648156
mutter does not support multiple X11 screens
Last modified: 2014-12-31 00:13:18 UTC
Overview: When attempting to start mutter while X11 is configured to have multiple Screens, it will fail with the above-mentioned X11 error. Steps to Reproduce: 1) Configure X.org to have more than one Screen. 2) Start mutter. Expected Results: 1) mutter starts and manages more than one Screen. Actual Results: 1) mutter stops with X11 error. Additional information: See attached backtrace.
Created attachment 186234 [details] Stack trace of crash.
Hm... I was sure someone had already filed this, but now I can't find it. It must have been one of the bugs lost in the server crash. Anyway, there is no theoretical reason why this could not be fixed, but it's currently *heavily* broken, and low priority.
*** Bug 650787 has been marked as a duplicate of this bug. ***
GNOME3 starts for me with multiple displays but always in fall-back mode. I know the hardware can support it since selecting TwinView gives we GNOME Shell across both displays [one scrolls with workspaces and one doesn't]. But the environment is shell and accelerated. NVIDIA Driver 270.41.06 Linux-x86_64 X.Org 1.9.3 (10903000) GeForce GT 230M openSUSE 11.4 Locking the screen and unlocking reverts to the expected single display mirrored on both displays.
(In reply to comment #4) > GNOME3 starts for me with multiple displays but always in fall-back mode. I > know the hardware can support it since selecting TwinView gives we GNOME Shell > across both displays [one scrolls with workspaces and one doesn't]. But the > environment is shell and accelerated. > > NVIDIA Driver 270.41.06 Linux-x86_64 X.Org 1.9.3 (10903000) > GeForce GT 230M openSUSE 11.4 > > Locking the screen and unlocking reverts to the expected single display > mirrored on both displays. This sounds like a bug, but I don't think it's this one.
*** Bug 651421 has been marked as a duplicate of this bug. ***
Configuring two separate screens with Nvidia settings i have a "Oh no! Something has gone wrong" message after login. Ubuntu 11.04 Gnome3 ppa gnome3team repository.
Confirming bug, on Arch Linux with Gnome 3.0.2. I currently do not run Gnome due to this bug, hope it gets resolved soon. If I can provide any data that would be helpful just let me know. :)
(In reply to comment #8) > I currently do not run Gnome due to this bug, hope it gets resolved soon. > If I can provide any data that would be helpful just let me know. :) As already mentioned above, no one is working on this, and it would be *a lot* of work to fix. Step one would be to fix plain mutter (ie, /usr/bin/mutter, not /usr/bin/gnome-shell) to support multiple screens. The most noticeable problem here is that meta_compositor_manage_screen() always calls clutter_stage_get_default(), meaning each screen would get the same stage (which won't work at all since the default stage is in a window on the default screen). This would need to use clutter_stage_new() and clutter_x11_set_stage_foreign() instead, at least for screens other than the default. There are probably additional problems beyond this. Once mutter with the default plugin works with multiple screens, the next step is probably to change how the plugin mechanism works with respect to multiple screens. Currently mutter creates a separate plugin for each screen, but that doesn't really make a lot of sense with complex plugins like gnome-shell. It should create a single plugin, but just expose a list of screens to the plugin instead of only a single screen. Finally, the really hard part. Gnome-shell assumes in like 1000 different places that there is only one screen and one stage. All of those places would have to be updated to do the right thing in a multi-screen environment. This would also mean figuring out how to make the additional screens behave with respect to the overview, workspaces, etc.
*** Bug 649676 has been marked as a duplicate of this bug. ***
*** Bug 656355 has been marked as a duplicate of this bug. ***
How can this bug get escalated for some attention - it must be driving people mad; not least some of the developers themselves who must have multiple screens for their development within GNOME3 itself?
(In reply to comment #12) > How can this bug get escalated for some attention - it must be driving people > mad; not least some of the developers themselves who must have multiple > screens for their development within GNOME3 itself? We use multiple displays with one X screen.
(In reply to comment #12) > How can this bug get escalated for some attention By attaching a patch - as Dan said, this is low priority and nobody is working on this. > it must be driving people mad; not least some of the developers themselves > who must have multiple screens for their development within GNOME3 itself? It looks like you are confusing screens with displays. An X11 screen is an abstract concept to group input (mouse, keyboard, ...) and output devices ("display" == monitor) together. A single screen can contain multiple X11 Devices, which mutter supports just fine.
...as do I for a pair of 21" wide-screens and it works well enough (using nVidia's latest 280 proprietary drivers on a twin-DVI GTX580 in TwinView mode). The problem (and, please suggest as workaround if it's known!) I have is when I launch XBMC in 'full-screen' mode (as opposed to 'windowed') it tries to stretch across both panels and is unusable in this state. There was a wmctrl workaround/trickery for this in Ubuntu (which worked) but I don't believe this has been ported to Fedora (yet/if at all). In addition; I've recently just added a second discrete GT430 for HTPC use and 'TwinView' isn't an option (probably for the reason that most boards can't drive a third screen?). The only option to enable this panels output is 'Separate X Screen'; which, again - GNOME3 balks when I attempt to login... I've just read Florian's timely response (I appreciate both by the way!) and he's suggesting a conceptual misunderstanding (between the two Devices I'm using (GTX580 and GT430), the two Screens (one being a TwinView 2x1080 and '1x1080 'Separate X Display): I'm more than willing to experiment with some hand-crafted xorg.conf files if it will result in being able to use all 2x21" and 1x40" panels simultaneously in GNOME3 (and, ideally; have XBMC run full-screen off the dedicated GT430). Below is a config that nvidia-settings has just generated when I configure my ideal personal layout - I've just noticed it doesn't seem to include a second 'Monitor' for my other Dell U2211H?! Could this be where things are going wrong? If you're able to see a glaring mistake in my xorg.conf - please do let me know! (Please excuse the direct copy/paste as I'm not sure whether adding an attachment is actually destined for patching suggestions!) Any assistance would be greatly appreciated. John # nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 280.13 (buildmeister@swio-display-x86-rhel47-03.nvidia.com) Wed Jul 27 17:15:45 PDT 2011 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 1920 0 Screen 1 "Screen1" LeftOf "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" FontPath "/usr/share/fonts/default/Type1" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from data in "/etc/sysconfig/keyboard" Identifier "Keyboard0" Driver "keyboard" Option "XkbLayout" "gb" Option "XkbModel" "pc105" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "Unknown" ModelName "DELL U2211H" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 Option "DPMS" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Unknown" ModelName "SONY TV" HorizSync 14.0 - 70.0 VertRefresh 48.0 - 62.0 EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce GTX 580" BusID "PCI:1:0:0" EndSection Section "Device" Identifier "Device1" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce GT 430" BusID "PCI:4:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "TwinView" "1" Option "TwinViewXineramaInfoOrder" "DFP-0" Option "metamodes" "DFP-0: 1920x1080_60 +0+0, DFP-2: 1920x1080_60 +1920+0" SubSection "Display" Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Device1" Monitor "Monitor1" DefaultDepth 24 Option "TwinView" "0" Option "metamodes" "1920x1080 +0+0" SubSection "Display" Depth 24 EndSubSection EndSection (In reply to comment #13) > (In reply to comment #12) > > How can this bug get escalated for some attention - it must be driving people > > mad; not least some of the developers themselves who must have multiple > > screens for their development within GNOME3 itself? > > We use multiple displays with one X screen.
Well what if we could create a workaround this issue - since my second monitor is my TV, and since gnome-shell is causing so much tearing when playing a video *it would be a better idea to assign a different non compositing window manager for the TV* However this would require that we could specify in the gnome-session which window manager that's to be asigned to each display. Simply like this would be my idea. Display :0.0 -> Gnome Shell Display :0.1 -> Gnome Fallback or a non compositing *box-wm However i have not been able to achive this yet, however that would be a perfect solution for me atleast. Regards Peter Johansson
I would also like to see mutter/gnome-shell to at least start up with the second screen unhandled until this possibly could be resolved, or does this also require big amounts of work? :D
Can confirm this bug that makes Gnome3 unusable for me. TwinView is not an option because the two display devices (TFT screen, TV) have different sync rates which causes tearing in TwinView mode. __GL_SYNC_DISPLAY_DEVICE doesn't do anything for me and I need the nvidia drivers (for VDPAU), so my only option is to go back to Gnome 2 :(
(In reply to comment #18) > so my only option is to go back to Gnome 2 :( There is the GNOME 3 Fallback mode.
(In reply to comment #19) > (In reply to comment #18) > > so my only option is to go back to Gnome 2 :( > > There is the GNOME 3 Fallback mode. So that's what you recommend instead of fixing this bug?
No, I just provided an alternative to your "only option" for the time being.
*** Bug 665234 has been marked as a duplicate of this bug. ***
*** Bug 665545 has been marked as a duplicate of this bug. ***
Wow. I can't believe GNOME 3 was taken out of the oven before this part was even remotely baked. It seems that every time and every avenue I take to try to give GNOME 3 a chance I find something else that is only half (and not even half in the case of dual screens it seems) baked. I really hate always being so critical of GNOME 3 (I was even kicked off of the gnome-users list because I was not all peachy and giddy about GNOME 3 but that is a censorship issue of a different matter) as I have been a GNOME user since it's first days, but was anyone other than grandma, reading her kids e-mail and seeing her grandkids on Facebook considered before GNOME 3 was considered "release worthy" and the last functional release of GNOME (2.x) was abandoned? I'm all for progress but a release (3.x) that has sooooo many regressions (compared to the release that was abandoned -- 2.x) is not progress but is regress. It's bad enough that this use-case (multiple screens) was not even considered during development but even after development nobody is even working on fixing such a fundamental defect with X11 environments. Yes, X11 environments can have more than one screen. How did this ever pass basic testing, or basic design even? I really, really do want to give GNOME 3 a fair shot (now that MGSE has made it somewhat usable) but how am I supposed to when every time I try it out such basic and fundamental use-cases simply don't work?
The suggested potential solution as described by "Pete" in comment 16 would probably be a decent enough band-aid to make Gnome 3 a viable for me.
*** Bug 665848 has been marked as a duplicate of this bug. ***
+1 for the solution in comment 16
Can I help to get this bug out of UNCONFIRMED status?
(In reply to comment #28) > Can I help to get this bug out of UNCONFIRMED status? Attach a patch. If you are only referring to changing the status to NEW or CONFIRMED, we ignore those statuses in mutter (e.g. NEW or CONFIRMED does not in any way mean the issue is closer to being fixed than with UNCONFIRMED)
How hard would Comment 16 solution be to implement? How many hours of coding would it be for an existing member of the Gnome development team to do? What sort of hourly rate would one of you ask?
Fixing mutter to only manage the first screen? It would be replacing the loop in: http://git.gnome.org/browse/mutter/tree/src/core/display.c#n350 with something that decides to only manage the item in the list. Whether or not Owen will take such a solution is not up to me.
Created attachment 206604 [details] [review] Only manage the first X screen if there are many (In reply to comment #31)
(In reply to comment #32) > Created an attachment (id=206604) [details] [review] > Only manage the first X screen if there are many > > (In reply to comment #31) Disclaimer - I have not tried to compile or tested this trivial patch.
(In reply to comment #33) > (In reply to comment #32) > > Created an attachment (id=206604) [details] [review] [details] [review] > > Only manage the first X screen if there are many > > > > (In reply to comment #31) > > Disclaimer - I have not tried to compile or tested this trivial patch. I have compiled and tested the patch. mutter RPMs are at http://koji.fedoraproject.org/koji/taskinfo?taskID=3757896 , and gnome-session RPMs (gnome-session-check-accerated-helper to not complain about Zaphod mode) are at http://koji.fedoraproject.org/koji/taskinfo?taskID=3757894 . It runs but I get fallback mode, possibly for some reason unrelated to this bug.
(In reply to comment #32) > Created an attachment (id=206604) [details] [review] > Only manage the first X screen if there are many So to be clear, you get two screens, one with switchable desktops and one without? i.e. one that is static with only a single desktop?
You get whatever you had before, but with mutter only managing the first X screen.
(In reply to comment #36) > You get whatever you had before, There is no "before". I don't have anything at all at the moment (since GNOME3 is unusable on my current hardware configuration) so please bear with my ignorance. > but with mutter only managing the > first X screen. So the second screen is a "bare" screen with no window management at all? If so, what use is that (I am asking that seriously)?
> > but with mutter only managing the first X screen. > > So the second screen is a "bare" screen with no window management at all? If > so, what use is that (I am asking that seriously)? That is very useful for people wanting to run another window manager on the second screen, like me who want to run Gnome 3 on Screen 1 and XFCE on Screen 2 Since i can turn off composite in XFCE, it will be perfect for .video-playback with no video-tearing.
I was wondering if that (running a second WM on the second screen) would be possible. So if this is possible, why couldn't one run two mutters then, on on each screen? Doesn't this then resolve the whole problem?
(In reply to comment #39) > I was wondering if that (running a second WM on the second screen) would be > possible. > > So if this is possible, why couldn't one run two mutters then, on on each > screen? Doesn't this then resolve the whole problem? Not until mutter won't cause any more tearing in video-playback
(In reply to comment #39) > I was wondering if that (running a second WM on the second screen) would be > possible. > > So if this is possible Sure, window managers can run on the second screen. I'm talking about screen in the X sense, though, not in the "LCD/panel/etc. that I can see" sense, like this page is talking about: http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop > why couldn't one run two mutters then, on on each > screen? Because right now, each mutter would try to manage all the X screens.
(In reply to comment #40) > > Not until mutter won't cause any more tearing in video-playback With all due respect, I think there are general usabilty issues with mutter and multiple screens (:0.0, :0.1, etc.) are a lot more important than "tearing". If my only problem was tearing, I wouldn't still be using GNOME2. (In reply to comment #41) > > Sure, window managers can run on the second screen. I'm talking about screen > in the X sense, though, Yes screen as in :0.0 is a screen and :0.1 is a different screen. > Because right now, each mutter would try to manage all the X screens. But doesn't the patch in this bug change mutter to only manage one screen? It does say "Only manage the *first* X screen if there are many" but how difficult would it be to change it to only managing (any) one screen rather than the "first" screen?
gnome-shell still crashes with this fix in libmutter, any way to also get this working?
(In reply to comment #43) > gnome-shell still crashes with this fix in libmutter, any way to also get this > working? See comment #9 - fixing mutter is only the first step, in order to get gnome-shell running in a multi-screen environment, more work is necessary.
Let me rephrase that, i meant the hack in comment #32 :D
(In reply to comment #42) > (In reply to comment #41) > > Because right now, each mutter would try to manage all the X screens. > > But doesn't the patch in this bug change mutter to only manage one screen? Yes. When I said "right now", I meant "mutter HEAD [that we are trying to change]". > how difficult > would it be to change it to only managing (any) one screen rather than the > "first" screen? More difficult than a one-line patch ;). I agree your suggestion would be better, but that involves configuration syntax changes (& code changes to cope), documentation changes, etc. I'm interested in seeing if it works *at all* / how far we can get with some multi-screen behaviour so that someone can be convinced to do it properly.
The patch wouldn't be too hard: g_getenv, atoi, g_slist_nth.
I would Like to turn my second monitor on its side - it's easier to read. Normally I would use separate x screens, and rotate, to do this. Is rotating the second display possible in gnome3 in it's current manifestation? By the way, I know haters are gonna hate, but i'd just like to say some positive things about gnome3. gnome3 is really simple, intuitive and usable. Kudos to the devs.
(In reply to comment #48) > I would Like to turn my second monitor on its side - it's easier to read. That's what I do. > Normally I would use separate x screens, and rotate, to do this. That's what I am doing. > Is rotating the second display possible in gnome3 in it's current > manifestation? Not at all. This configuration makes it completely impossible to use Gnome 3 which is why I am now using MATE. > gnome3 is really simple, intuitive and usable. Not if you want a screen on it's side it's not. Or even if you just want separate X screens (not one big merged one like twinview, Xinerama, etc.).
(In reply to comment #48) > Is rotating the second display possible in gnome3 in it's current > manifestation? System Settings -> Displays, select the monitor preview you want to adjust, choose the orientation you want in the "Rotation" combo box. (This is assuming your graphics driver supports a recent enough Xrandr, e.g. not the proprietary nvidia driver)
(In reply to comment #50) > > (This is assuming your graphics driver supports a recent enough Xrandr, e.g. > not the proprietary nvidia driver) Right. Which then precludes what percentage of users? But proprietary nvidia driver aside this ultimately this still falls short of my desires which is two separately managed screens, each with multiple workspaces where changing to a workspace on one screen does not change the other.
I just tried the patch in post 32 with mutter 3.3.90 and I still get mutter segfaulting when I login to gnome-shell. I'm using Ubuntu 12.04 and I cannot see any difference between mutter in the repo's and the mutter I compiled. My system is dual gpu, with a total of 4 x screens, but only one monitor, so my understanding is the patch in post 32 should allow me to use x screen 0 for gnome-shell/mutter and keep all 4 x screens available for OpenCL work. Is this correct?
(In reply to comment #52) > so my understanding is the patch in post 32 should allow me to use x screen 0 > for gnome-shell/mutter and keep all 4 x screens available for OpenCL work. > Is this correct? No, I'm pretty sure GNOME Shell needs patching as well (and no such patch exists at the moment). So the patch in attachment 206604 [details] [review] should allow you to run mutter (and mutter alone) with multiple X11 screens, not gnome-shell (note that I have not tested the patch myself, so no idea if it'd need updating as well).
In my case, where all I need is for gnome-shell to only appear/manage on one physical monitor (and x screen), would the patch gnome-shell requires be relatively straightforward like in post 32? Or would it be more difficult to get gnome-shell to ignore all x screens except for one?
I just tried the patch in post 32 on mutter, gnome-shell 3.3.92 and again it is not working. Could someone please look at what is required to get the current mutter and gnome-shell to only run on a single specific xscreen when multiple exist? I'm not a programmer, but I really didn't think it'd be tremendously time-consuming to get gnome-shell and mutter to ignore all the other xscreens, especially as it can't yet properly manage them, so no functionality would be lost. I honestly thought this would have been the default behaviour for gnome-shell until it can properly support multiple xscreens, as opposed to refusing to run at all.
*** Bug 672888 has been marked as a duplicate of this bug. ***
I could potentially put some paid time towards this because it is killing us at work. Beyond the mutter patch, care to outline what gnome-shell changes might be needed? I also recall recent clutter patches that tidied up the default stage logic.
(In reply to comment #57) > Beyond the mutter patch, care to outline what gnome-shell changes might be > needed? I also recall recent clutter patches that tidied up the default stage > logic. To make gnome-shell work with multiple screens, or to just make gnome-shell take over one screen?
(In reply to comment #58) > (In reply to comment #57) > > Beyond the mutter patch, care to outline what gnome-shell changes might be > > needed? I also recall recent clutter patches that tidied up the default stage > > logic. > > To make gnome-shell work with multiple screens, or to just make gnome-shell > take over one screen? The latter. Initially to ignore all except the first screen in a multi-screen environment.
Created attachment 213261 [details] [review] Only manage the first X screen This is all that is required to make mutter/gnome-shell ignore X screens > 1. (you also need to patch gnome-session-check-accelerated-helper to not die if multiple screens are detected 'zaphod mode')
How is this not confirmed? It's so easy to reproduce...
peter: Confirmed and unconfirmed are no difference in GNOME Bugzilla.
Florian, does the patch look good ?
(In reply to comment #63) > Florian, does the patch look good ? It looks like a hack. If there was a comment explaining what's going on, I'd consider it an okay-hack, though I guess that picking a particular screen from the environment would still be better (and not really that complicated either).
Created attachment 223944 [details] [review] Only manage the default X screen The attached patch uses the default screen, i.e., the screen specified by the DISPLAY environment variable. Not extensively tested yet, but I was able to start two gnome-shell instances in a dual-head virtual machine (using a second D-Bus session).
Created attachment 223945 [details] [review] gnome-session: Support zaphod mode For completeness, here is the gnome-session patch to not error out when run on an X display with multiple screens.
Both attachments are for mutter.
Created attachment 223946 [details] [review] gnome-session: Support zaphod mode Sorry about that. Here is the gnome-session patch to not error out when run on an X display with multiple screens.
Created attachment 224010 [details] [review] gnome-shell: Do not acquire bus name on non-primary X screen If anyone wants to try running multiple instances of gnome-shell in the same D-Bus session bus, the attached patch allows that by not acquiring bus names when starting gnome-shell on non-primary X screen. It appears to work ok but it's not exactly an elegant solution.
Could at least the first patch (only manage the default screen) get a review ? I think we should perhaps merge that - it is certainly better than an ugly crash.
(In reply to comment #70) > Could at least the first patch (only manage the default screen) get a review ? > I think we should perhaps merge that - it is certainly better than an ugly > crash. I think it's more appropriate to say that we don't support Zaphod mode at this point in time.
(In reply to comment #71) > I think it's more appropriate to say that we don't support Zaphod mode at this > point in time. Any reason for this? While I can understand that you don't want to support multiple X screens in a single process, I don't see anything speaking against supporting a single X screen in Zaphod mode. It doesn't add any code complexity.
(In reply to comment #71) > (In reply to comment #70) > > Could at least the first patch (only manage the default screen) get a review ? > > I think we should perhaps merge that - it is certainly better than an ugly > > crash. > > I think it's more appropriate to say that we don't support Zaphod mode at this > point in time. FWIW we are using debs built with Jurg's patches on in our lab (the second head / xscreen is used to visual stimulus experiments). The patch is the only thing that lets us use gnome-shell on the first screen. Otherwise we would have to use unity.
Excuse the slightly OT user question but is it really about not *wanting* to support several X-Screens? And if so - why?
(In reply to comment #71) > I think it's more appropriate to say that we don't support Zaphod mode at this > point in time. The patch is not about supporting multiple screens, but about not trying to manage more than one screen if you can't handle it.
(In reply to comment #75) > > The patch is not about supporting multiple screens, but about not trying to > manage more than one screen if you can't handle it. And simply not just crashing out with no indication as to why when multiple screens are present. You know, I am trying really hard to bite my tongue here on my opinions about such a nasty regression in what is fundamental X11 functionality lest I be censored (read: banned -- simply for expressing a negative opinion of GNOME 3) here as I have been on the gnome-list but seriously: is having a patch that at least doesn't crash mutter out completely with dual screens really that bad?
(In reply to comment #76) > You know, I am trying really hard to bite my tongue here on my opinions about > such a nasty regression in what is fundamental X11 functionality lest I be > censored (read: banned -- simply for expressing a negative opinion of GNOME 3) You won't be. Note that Zaphod Mode is considered deprecated too -- I don't know of anything that still uses it that can't simply use RandR, and I've heard that some Xorg code that supported some edge cases in it has been ripped out, simply because it was causing too much cruft in the codebase for a mode that nobody has simply used upstream. > here as I have been on the gnome-list but seriously: is having a patch that at > least doesn't crash mutter out completely with dual screens really that bad? No, I guess. I was more talking about the gnome-session patches.
Review of attachment 223944 [details] [review]: Yeah, this is a good patch. ::: src/core/display.c @@ +825,2 @@ + if (screen) + screens = g_slist_prepend (screens, screen); Bonus points if you add comment at the declaration of "screens" declaring some history about how mutter used to manage more than one screen, but now it's only one, but the list is left for simplicity would be nice.
If Zaphod Mode == multi-seat configuration, which is the definition I seem to keep finding (http://www.x.org/wiki/FAQ) then indeed, I have next to no interest in that. What I am interested in is true multiple screen (:0.0, :0.1, etc.) support and not Xinerama or any of the video card vendor hacks like twinview, etc. where they merge the screens in the GPU and present a single logical screen to X11. The reason I need true multiple screen support is that one of my screens is actually rotated 90 degrees and I want to be able to workspace flip each screen independently of the other.
(In reply to comment #79) > If Zaphod Mode == multi-seat configuration, which is the definition I seem to > keep finding (http://www.x.org/wiki/FAQ) then indeed, I have next to no > interest in that. As far as I'm aware, Zaphod Mode meant multi-screen, not multi-seat. Multi-seat is supported in GNOME Shell starting with F17. > The reason I need true multiple screen support is that one of my screens is > actually rotated 90 degrees and I want to be able to workspace flip each screen > independently of the other. RandR should let you do that. It still merges the output into one giant buffer, but allows you to Resize and Rotate (RandR) each head independently.
We might want to refresh the terminology then. Everywhere I read about zaphod mode it referred to multi-seat. In any case, I specifically don't want one single big screen -- whether that's done with Xinerama, by the GPU, RandR, or anything else. I specifically want independently addressable screens. Yes, I understand that I don't get to drag windows across them, but that's the least important of feature tradeoffs IMHO. Being able to have a primary screen where I have my primary work functions on separate workspaces and being able to flip amongst them while I keep (say) e-mail on my other screen (almost always, but workspace flippable for other much more occasional need) present is hugely important to me. It's a deal breaker. If GNOME is going to deprecate that functionality and never again support it, I might as well just cut bait now since I will never use GNOME again, I'm afraid. It's deeply saddening that such choice is being taken away.
GNOME lets you treat monitors in two ways currently: Either you get workspaces on the primary, and a separate, workspace-less second monitor. Or you get workspaces that stretch across both monitors. We don't have a mode in which you have independent workspaces on both heads. All of this is entirely separate from the question of whether the monitors are one or more screens for X.
> > All of this is entirely separate from the question of whether the monitors are > one or more screens for X. Exactly. I don't care what it is called - I use the first X screen for gnome-shell (:0.0) and subsequent X screens for experiments. I'm perfectly happy that GS doesn't try to work across multiple X screens, but refusing to run when it is easily possible is silly. So please commit the gnome-session patch too.
(In reply to comment #80) > RandR should let you do that. It still merges the output into one giant buffer, > but allows you to Resize and Rotate (RandR) each head independently. I don't know if this matters but there's also the case that you want to have a GNOME desktop on one screen and the second screen (HDMI-TV) to view movies without tearing. For this purpose, at least with current nvidia video drivers it seems to be necessary that there are two X screens (else there are vsync problems). If this case is covered by your design "as it should be", please ignore this comment.
Wholeheartedly agree with Andreas. It's this capability that I'm patiently awaiting. For me personally; I have a pair of 21" 19:9 1080p panels via nVidia TwinView (which work pretty well now in GNOME Shell) with an additional Sony Bravia 40" 1080p which I'd like to be a discrete X-screen for hosting a permanent XBMC media centre window within - or, the ability to play Bluray content via VLC or SMPlayer within (or even host a separate browser session in). (To be clear; I have two graphics boards installed; a dual-DVI nVidia GTX580 and an another single HDMI-port nVidia GT430 for the TV). I imagine there must be a *very* large number of people also wanting this typical arrangement. Gents, appreciate the efforts thus far. Kind regards, John
One and an half year later, nothing has changed?! @ Comment 85 "I imagine there must be a *very* large number of people also wanting this typical arrangement." Sure. They are just still using gnome2. Gnome3 seems to stay a kindergarten-wm which is just used on tablets and by ubuntu users... Linus Torvalds about Gnome3: "total user experience design failure" https://plus.google.com/+LinusTorvalds/posts/UkoAaLDpF4i Thats saying all. Hopefully there will be some usable gnome2 fork For the xinerama,xrandr,twinview-trolls: can you rotate seperate screens on the fly? do you have own panels & workspaces for your each monitor? if not, don't tell us to just use that crap... :p
Comment on attachment 223944 [details] [review] Only manage the default X screen commit 1a521e10c3ee3dea34e82bc708aaf5a2b75eca14 Author: Jürg Billeter <j@bitron.ch> Date: Mon Sep 10 20:19:21 2012 +0200 display: Only manage the default X screen https://bugzilla.gnome.org/show_bug.cgi?id=648156
Comment on attachment 223946 [details] [review] gnome-session: Support zaphod mode Marking the gnome-session patch as obsolete as it doesn't really belong to this mutter bug report. I've attached the patch to gnome-session bug 665061.
(In reply to comment #86) > @ Comment 85 > "I imagine there must be a *very* large number of people also wanting this > typical arrangement." > > Sure. They are just still using gnome2. In my case, my friend whose PC is connected to the TV is forced to use Unity because Gnome3 crashes in this configuration (and he won't use Gnome2 when Gnome3 is available in the distros). > Gnome3 seems to stay a kindergarten-wm which is just used on tablets and by > ubuntu users... I know that this is not a forum but a bug report and I just want to state that I'm very happy with Gnome3 and that I like the new UI *much* better than the Gnome2 one (and I don't care what Linus Torvalds is thinking about it). Sorry for this, I just could not resist. I will stay on topic in further messages.
(In reply to comment #87) > (From update of attachment 223944 [details] [review]) > commit 1a521e10c3ee3dea34e82bc708aaf5a2b75eca14 > Author: Jürg Billeter <j@bitron.ch> > Date: Mon Sep 10 20:19:21 2012 +0200 > > display: Only manage the default X screen > > https://bugzilla.gnome.org/show_bug.cgi?id=648156 This commit seems to break logins to GNOME -- about a minute after login, gnome-session displays the "Fatal error" screen and logs the following message: gnome-session[1324458]: WARNING: Application 'gnome-shell.desktop' failed to register before timeout
(In reply to comment #90) > This commit seems to break logins to GNOME -- about a minute after login, > gnome-session displays the "Fatal error" screen and logs the following message: I've been using this for weeks without issues on top of 3.4.1 and now as part of 3.6.1. Did you use git bisect or how did you determine the faulty commit? I don't see how this patch can change anything on systems with a single X screen.
(In reply to comment #91) > I don't see how this patch can change anything on systems with a > single X screen. Could this be the result of the (uncommitted) gnome-shell patch when running something else on screen 0 and the shell on some other screen?
(In reply to comment #91) > (In reply to comment #90) > > This commit seems to break logins to GNOME -- about a minute after login, > > gnome-session displays the "Fatal error" screen and logs the following message: > > I've been using this for weeks without issues on top of 3.4.1 and now as part > of 3.6.1. > > Did you use git bisect or how did you determine the faulty commit? I don't see > how this patch can change anything on systems with a single X screen. Disregard my last comment – this actually seems to be a packaging issue; the original 3.6.1 appears to be not linked against libSM/libICE.
Just want to let the Gnome developers know that I first posted on this bug 17 months ago stating I do not use Gnome 3 due to this bug. 17 months later, the situation remains the same. I have not even looked at Gnome 3 since because the "separate X screen" functionality remains broken. I could try using the patches attached to this thread, but why bother, if this kind of issue doesn't warrant more and faster attention than this, what confidence can any 'power user' have in the future of Gnome 3.
(In reply to comment #94) > 17 months later, the situation remains the same. I have not even looked at > Gnome 3 since because the "separate X screen" functionality remains broken. (In reply to comment #25) > The suggested potential solution as described by "Pete" in comment 16 would > probably be a decent enough band-aid to make Gnome 3 a viable for me. The patches that are essential for the solution described in comment 16 - use mutter/gnome-shell on one screen and a different window manager on the other screen(s) - have been committed and are in GNOME 3.6. This means that GNOME no longer starts in fallback mode just because you have multiple X screens. gnome-session doesn't have built-in support for starting multiple window managers, however, you can easily add an autostart entry for DISPLAY=:0.1 some-other-wm.
Hi folks, just in case, I successfully use 3 display on 1 xserver thanks to the basemosaic option of the nvidia-xconfig tool and gdm. http://us.download.nvidia.com/solaris/275.21/README/xconfigoptions.html
(In reply to comment #96) > Hi folks, > > just in case, I successfully use 3 display on 1 xserver thanks to the > basemosaic option of the nvidia-xconfig tool and gdm. Which is _completely_ irrelevant to this bug. Notice that the summary of this bug is: "mutter does not support multiple X11 screens" ^^^^^^^^ basemosaic appears to just create a single "screen" (as far as X11 sees) at the hardware level. This is not an acceptable solution to this problem as there are many scenarios where a single screen is not desired or even workable.
(In reply to comment #0) > Overview: > > When attempting to start mutter while X11 is configured to have multiple > Screens, it will fail with the above-mentioned X11 error. > > Steps to Reproduce: > > 1) Configure X.org to have more than one Screen. > 2) Start mutter. > > Expected Results: > > 1) mutter starts and manages more than one Screen. > > Actual Results: > > 1) mutter stops with X11 error. > > Additional information: > > See attached backtrace. In Gnome 3.6 ive sucessfully gotten multiple displays working, here's my Xorg config. http://unlogical.net/files/cfgs/xorg/xorg.conf * Note, you might need to change the drivers in the device section * Option "metamodes" "DFP-1: 800x600 +0+0" Remove this line if you want to use a higher resolution on the second display * Screen 1 "Screen1" 2000 0 - This places my second monitor far away from the first one, jailing the mouse on display 1, You maybe wish to change this.
Something here can be related with https://bugzilla.gnome.org/show_bug.cgi?id=650994 ?
nVidia's basemosaic doesn't work on Ubuntu 12.10. It all hangs so you have to power off. Don't waste your time on this. basically: must have screen-device-monitor in xorg.conf device section: must pick the right device using busid in device section (it will gracefully error if you got the wrong one) Option "NoLogo" "1" Option "ProbeAllGpus" "false" -- otherwise it will crash with some protection jibberish screen section: Option "BaseMosaic" "True" Option "MetaModes" "GPU-0.DFP-0: 1920x1200+0+0, GPU-1.DFP-2: 2560x1600+1920+0, GPU-1.DFP-1: 1920x1200+4480+0" Option "SLI" "mosaic" adjust your metamodes launches EXTREMELY slowly until it no longer works. must power off to recover video. in syslog: eb 17 10:58:51 c505 gdm-simple-slave[1734]: GLib-GObject-CRITICAL: g_object_ref: assertion `object->ref_count > 0' failed Feb 17 10:58:51 c505 gdm-simple-slave[3571]: WARNING: Child process 3575 was already dead. Feb 17 10:58:51 c505 gdm-simple-slave[3571]: GLib-GObject-CRITICAL: g_object_ref: assertion `object->ref_count > 0' failed Feb 17 10:58:51 c505 gdm-simple-slave[3571]: GLib-GObject-CRITICAL: g_object_unref: assertion `object->ref_count > 0' failed Feb 17 10:58:51 c505 gdm[3561]: WARNING: Child process 3571 was already dead. Feb 17 10:58:51 c505 gdm[3561]: WARNING: Unable to kill slave process Feb 17 10:58:51 c505 gdm[3561]: WARNING: Child process 3571 was already dead. Feb 17 10:58:51 c505 gdm[3561]: WARNING: Unable to kill slave process Feb 17 10:58:51 c505 gdm[3561]: WARNING: GdmDisplay: display lasted 0.022708 seconds
I would love to use Gnome shell, but I have waited two years for it in fallback. An increasing problem is that css3d crashes the gpu for 10 s when using Google Chrome if you're a fallbacker. The solution at the moment for us multi-gpu:ers is kde On ubuntu 12.10 install kde-standard package and select kde session on X login xorg.conf: layout section: Option "Xinerama" "1" extensions section (ie. can delete this) Option "Composite" "1" main device section: Option "NoLogo" "1" # add 130221 at 20:17 Option "ProbeAllGpus" "false" # add 130221 at 20:17 -- otherwise won't start now you have: xinerama dpms composite dri2 vdpau glx 2d-acceleration on multiple gpus now you don't have: usable-randr, ARGB nVidia disables 32-bit ARGB GLX visuals, you can get it if you lose xinerama - the visual bell that wastes seconds of you life is finally gone - Chrome can display css3d without taking multiple 10 s periods out of your life for gpu crashes chrome://gpu/ now has: Canvas: Software only, hardware acceleration unavailable Compositing: Hardware accelerated 3D CSS: Hardware accelerated CSS Animation: Accelerated WebGL: Hardware accelerated WebGL multisampling: Hardware accelerated Flash 3D: Unavailable. Hardware acceleration unavailable Flash Stage3D: Unavailable. Hardware acceleration unavailable Texture Sharing: Hardware accelerated Video Decode: Software only, hardware acceleration unavailable Video: Software only, hardware acceleration unavailable Panel Fitting: Unavailable. Hardware acceleration disabled. Force Compositing Mode: Unavailable. Hardware acceleration disabled. Again, I'd prefer gnome shell any day of the week.
(In reply to comment #95) > > The patches that are essential for the solution described in comment 16 - use > mutter/gnome-shell on one screen and a different window manager on the other > screen(s) - have been committed and are in GNOME 3.6. This means that GNOME no > longer starts in fallback mode just because you have multiple X screens. > > gnome-session doesn't have built-in support for starting multiple window > managers, however, you can easily add an autostart entry for DISPLAY=:0.1 > some-other-wm. I have been stuck in ancient fedora for years now due to the issue in this thread. This comment seems like a reasonable interim solution for my purposes. However while it appears that the default Gnome3 desktop works (which is completely unusable) with the multi-screen config by occupying a single screen, unfortunately, Cinnamon (which seems usable) as the primary desktop is dying in this mode. I am using the latest stable FC18 and nvidia drivers as a fresh install in this attempt. Also, has anyone configured the second screen with another window manager (maybe KDE?), and if so, can you post the configuration needed. Tnx
What does <QUOTE> However while it appears that the default Gnome3 desktop works (which is completely unusable) with the multi-screen config by occupying a single screen, </QUOTE> mean? I am using GNOME Shell 3.8 on multi-display single-screen. It works flawlessly.
(In reply to comment #103) > What does > <QUOTE> > However while it appears that the default Gnome3 desktop works (which is > completely unusable) with the multi-screen config by occupying a single screen, > </QUOTE> > mean? It means he doesn't like GNOME 3 and wants us to fix Cinnamon (which apparently is missing the patch in this bug).
Florian you are correct... the standard gnome3 desktop does not fit my needs. Cinnamon appears to be a decent replacement for gnome2, but I guess is not patched. I incorrectly assumed that the patch was to mutter and not gnome-shell. Can we get a Cinnamon patch, or perhaps a patch to mutter so Cinnamon inherits the fix? Also, I guess I am a little dense, as I have tried a few things, but have failed to start up a different window manager on each screen. Could you give a step by step on that? Thanks!
You are correct that this is a mutter patch, but Cinnamon forked mutter as well as gnome-shell, so this is the wrong forum to ask for a fix.
Multiple X11 Screens are likely to never be supported given what a terrible idea they were. Sorry.
(In reply to comment #107) > Multiple X11 Screens are likely to never be supported given what a terrible > idea they were. Sorry. What is your basis for multiple X11 Screens being a terrible idea? What do you think is a better idea for handling multiple monitors?
Multiple X11 Screens don't support dragging windows from one monitor to the other or straddling windows across multiple Screens, they don't really have any dynamic reassignment (you can't add / remove X11 Screens at runtime for hotplug scenarios), and it comes from that period in the 80s where you one could have with displays with wildly different graphics capabilities (e.g. a monocolor bitmapped display and a really fancy, expensive, *pseudocolor* paletted display! Wow!) Today, displays are cheap, hotplug is considered a bog-standard feature, and the use cases for multiple X11 Screens are so niche that I don't want to support them. The X11 RandR extension allows configuring multiple displays and display controllers, and mutter supports it perfectly well. All FOSS drivers support RandR, and so does the proprietary AMD and NVIDIA drivers.
(In reply to comment #109) > Multiple X11 Screens don't support dragging windows from one monitor to the > other or straddling windows across multiple Screens, Right. For some people that's not a problem and in fact that displays are stretched across screens is an actual problem. > they don't really have any > dynamic reassignment (you can't add / remove X11 Screens at runtime for hotplug > scenarios), and it comes from that period in the 80s where you one could have > with displays with wildly different graphics capabilities (e.g. a monocolor > bitmapped display and a really fancy, expensive, *pseudocolor* paletted > display! Wow!) Or different sync rates. > Today, displays are cheap, hotplug is considered a bog-standard feature, and > the use cases for multiple X11 Screens are so niche that I don't want to > support them. Ahh. So it's not that multiple screens are "technically" a bad idea. It's just that they don't suit your personal workflow. But they do suit the workflows of other people. Massive single displays have just as many warts in other scenarios as discrete screens have in yours. They are not independently switchable workspaces for example. I cannot have my left display on workspace 1 and my right display on workspace 3. And I cannot then change my right display to workspace 4 and keep the left display on workspace 1. Lots of time I want to be able to continue viewing the same thing on my left display while I switch my right display's workspaces. > The X11 RandR extension allows configuring multiple displays and display > controllers, and mutter supports it perfectly well. The last time I tried mutter with multiple displays it outright crashed completely as soon as it started so I'm not sure that that qualifies as "perfectly well".
(In reply to comment #110) > The last time I tried mutter with multiple displays it outright crashed > completely as soon as it started so I'm not sure that that qualifies as > "perfectly well". Do you have a backtrace I can look at? That's a bug and shouldn't happen.
(In reply to comment #111) > (In reply to comment #110) > > The last time I tried mutter with multiple displays it outright crashed > > completely as soon as it started so I'm not sure that that qualifies as > > "perfectly well". > > Do you have a backtrace I can look at? That's a bug and shouldn't happen. Not any more. I have not used GNOME 3 for a long time now (I actually don't think I have ever used it beyond discovering that it crashed on startup due to this issue). I use MATE on my dual-head machine and Cinnamon on my laptop. I will paste one here if I can get it to reproduce.