GNOME Bugzilla – Bug 321094
Workspace Selection under Multi-Head configuration.
Last modified: 2005-12-22 06:32:29 UTC
Distribution: Debian testing/unstable Package: metacity Severity: normal Version: GNOME2.10.2 unspecified Gnome-Distributor: Debian Synopsis: Workspace Selection under Multi-Head configuration. Bugzilla-Product: metacity Bugzilla-Component: general Bugzilla-Version: unspecified Description: Description of Problem: A gnome session/metacity started on a multi-head configuration (:0.0 and :0.1, vs xinerama) when changing workspaces on secondary/etc.. screen it will shift focus to workspace selector on screen :0.0 Steps to reproduce the problem: 1. Start a multi-head xorg/xfree86 configuration, or even Xnest -scrns 2 and disable xinerama. 2. attempt to change workspaces on the secondary display, it will throw the workspace selector focus to screen :0.0 Actual Results: Will not allow key driven method of changing workspaces per head. Only via mouse action on workspace selection applet. Expected Results: Should continue to leave focus of workspace selector on originating head/screen. How often does this happen? Every time. Additional Information: Here is my example xorg.conf # XF86Config-4 (XFree86 X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 >/var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath "unix/:7100" # local font server # if the local font server has problems, we can fall back on these FontPath "/usr/lib/X11/fonts/misc" FontPath "/usr/lib/X11/fonts/cyrillic" FontPath "/usr/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/lib/X11/fonts/Type1" FontPath "/usr/lib/X11/fonts/CID" FontPath "/usr/lib/X11/fonts/Speedo" FontPath "/usr/lib/X11/fonts/100dpi" FontPath "/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load "GLcore" Load "bitmap" Load "dbe" Load "ddc" Load "dri" Load "extmod" Load "freetype" Load "glx" Load "int10" Load "record" Load "speedo" Load "type1" Load "vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "ImPS/2" Option "Resolution" "800" Option "Emulate3Buttons" "false" Option "ZAxisMapping" "4 5" EndSection #Section "InputDevice" # Identifier "Generic Mouse" # Driver "mouse" # Option "SendCoreEvents" "true" # Option "Device" "/dev/input/mice" # Option "Protocol" "ImPS/2" # Option "Emulate3Buttons" "false" # Option "ZAxisMapping" "4 5" #EndSection Section "Device" Identifier "Generic Video Card" Driver "nvidia" BusID "PCI:1:0:0" Option "NvAGP" "3" Option "RenderAccel" "true" Option "NoLogo" "true" Screen 0 EndSection Section "Device" Identifier "Secondary Video Card" Driver "nvidia" BusID "PCI:1:0:0" Option "NvAGP" "3" Option "RenderAccel" "true" Option "NoLogo" "true" Screen 1 EndSection Section "Monitor" Identifier "Generic Monitor" HorizSync 30-80 VertRefresh 55-75 Option "DPMS" UseModes "16:10" DisplaySize 1040 320 Option "UseEdidFreqs" "1" Option "FlatPanelProperties" "scaling=aspect-scaled" EndSection Section "Modes" Identifier "16:10" # ModeLine "1920x1200" 197.27 1920 2064 2272 2624 1200 1201 1204 1253 # ModeLine "1920x1200" 246.59 1920 2064 2272 2624 1200 1201 1204 1253 # ModeLine "1920x1200" 282.74 1920 2072 2280 2640 1200 1201 1204 1260 # ModeLine "1920x1200" 337.58 1920 2072 2288 2656 1200 1201 1204 1271 EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display" Depth 24 # Modes "1920x1200" # Modes "1024x768" "800x600" "640x480" EndSubSection EndSection Section "Screen" Identifier "Secondary Screen" Device "Secondary Video Card" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display" Depth 24 # Modes "1920x1200" # Modes "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "Multihead layout" Screen "Default Screen" 0 0 Screen "Secondary Screen" RightOf "Default Screen" Option "Xinerama" "off" EndSection Section "DRI" Mode 0666 EndSection ------- Bug moved to this database by unknown@gnome.bugs 2005-11-09 20:51 UTC ------- The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@gnome.bugs. Previous reporter was shane@tdxnet.com.
Is this a duplicate of bug 319423 (and perhaps bug 116041), or are there subtle differences (I never feel very sure having never used a multi-head setup...)?
I suggest starting a failsafe terminal session.. and starting Xnest -scrns 2 -geometry 800x800 -indirect localhost and logging in to your local machine as a way to test this behaviour.. Just as added experience for gnome developers not used to this display method. This is a duplicate to both those bugs.. 319423 and 116041, I used bugbuddy and wasn't aware of these bug reports. There will indefinatly be more bugs I will find. Its quite fun being able to drag desktop components atleast to different screens, thats quite cool.
Yeah, Havoc keeps on pointing out the Xnest thing too. It really bugs me, though, because I can't keynav inside the Xnest (e.g. alt-tab will switch from the Xnest to other windows when the Xnest has focus instead of switching among windows shown inside the Xnest window), and so I usually don't even want to bother. However, you keep suggesting using it. How did you get the workspace keybinding to switch workspaces for the Xnest'ed metacity instead of the outside global one? Did you just change all your keybindings (something I don't want to bother with). Honestly, though, I've contemplated putting in special handling for Xnest so that if it has focus, global keybindings are passed on to it instead of being used normally... Just had a hunch that this might be due to the bug we have filed somewhere saying that we don't place override redirect windows on the right screen under various circumstances (I don't recall the bug number and am too lazy to search atm, but thought I'd mention it while I was at it).
*** This bug has been marked as a duplicate of 319423 ***
from GDM, start failsafe console and start the xnest from there, yes this means tearing down your current gnome session :) Personally I: adduser testuser sudo X :1 -indirect localhost then log in as testuser under failsafe terminal and start up the X session. If you have multiple heads you could always start X on :1 with -layout (setup like above to ensure no xinerama) and then not worry about the Xnests at all. just test it out there. So basically.. get outside of your environment if you want to test this.
Bah, being required to exit my current session removes almost all the advantages. I'd rather patch metacity to treat Xnest special (which would be pretty useful in general anyway); I just need to find some time to figure that one out. :-)
In the immortal words of Charlie Brown: Good Grief!!
Hehe. :) Honestly, though, we have tons of multihead bugs both with and without xinerama and I don't want to have to log out for each new one that comes in or for all the testing required for each. Having an Xnest running within my environment that's not useless for testing (as is the current case with the keybinding setup) would be really nice. Besides, given the heavy testing of metacity I have to do for other features and all the crashes I cause in early versions, having a non-useless Xnest running inside my normal session, which I can use for _real_ testing would be very nice. I think I need to code it up.
Of couse.. I never asked you to log out.. its simple enough to start a failsafe session in a new X server that will have 0 effect on your current session, so that you can start up a new xnest environment. If you didn't want to do that you could always start up the xnest session in your current display.. log in as a testing user and change the users keymaps inside that session. Instant analysis and debugging.
Ok.. so I switched to xfwm4 temporarily and it totally does this 1 thing correctly :)..
The Xnest keybindings thing is why metacity-message has that "disable keybindings" feature, I added that so I could test keybindings inside an xnest. You could also do some sort of complicated grab-the-mouse-and-keyboard feature along the lines of how vmware works, but I'm not sure it's worth it.
Sweet, I probably should have known about that, but didn't. Thanks for the tip. ;-)
Don't know if you noticed, but I posted a patch in bug 319423 that seems to fix this bug for me; I would appreciate it if you could test it out too. Thanks.