After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319423 - workspace switcher breaks on second head
workspace switcher breaks on second head
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other Linux
: High major
: 2.14.x
Assigned To: Metacity maintainers list
Metacity maintainers list
: 116041 321094 325929 328643 464971 (view as bug list)
Depends on:
Blocks: 324772
 
 
Reported: 2005-10-21 15:34 UTC by Chris Lee
Modified: 2007-08-12 16:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Make one no_focus_window per screen (10.18 KB, patch)
2005-12-21 20:59 UTC, Elijah Newren
committed Details | Review

Description Chris Lee 2005-10-21 15:34:51 UTC
Version details: 2.10.3
Distribution/Version: Fedora Core 4

1) Enable dual-head display without Xinerama.
2) Switch workspaces on second head.
3) Workspace switcher does not go away when keys (e.g., Ctrl+Alt+RightArrow) are
released.
Comment 1 Elijah Newren 2005-10-21 16:10:21 UTC
Looks closely related to bug 116041 (might be the same, though they look
slightly different at first glance).

So, I don't have a dual-head setup anywhere that I can test, but this looked so
close to bug 147475 that I think I might be able to take a stab at it.  A quick
look through the code shows that we only have one no_focus_window instead of
having one per screen.  Taking a guess from bug 147475 comment 14 and the
relevant fix to that, I believe that this lack of one no-focus-window per screen
might be causing this bug.
Comment 2 Havoc Pennington 2005-10-23 17:36:04 UTC
It should be possible to test dual-head stuff with the metacity Xnest setup.
SCREENS=2 ./run-metacity.sh

In principle "currently focused window" is a property of the display not the
screen... it isn't obvious to me why a per-screen no focus window would change
anything?

Comment 3 Elijah Newren 2005-10-23 20:55:11 UTC
Oh, right....uh, nevermind then.  ;)

Also, good to know about the screens stuff--but it may not help without much
more pain since global keybindings (e.g. ctrl-alt-<arrow>) act on the Xnest
window instead of on the windows within the Xnest window.
Comment 4 Elijah Newren 2005-11-15 01:36:38 UTC
*** Bug 116041 has been marked as a duplicate of this bug. ***
Comment 5 Elijah Newren 2005-11-15 01:36:59 UTC
*** Bug 321094 has been marked as a duplicate of this bug. ***
Comment 6 Elijah Newren 2005-12-21 20:59:06 UTC
From keybindings.c:meta_display_process_key_event():
  /* if key event was on root window, we have a shortcut */
  screen = meta_display_screen_for_root (display, event->xkey.window);
event->xkey.window is display->no_focus_window, whose screen is always Screen 0.  That's the cause of this bug, so it turns out I was actually right in comment 1.

I'll attach a patch in a minute which fixes this bug by keeping one no_focus_window per screen.
Comment 7 Elijah Newren 2005-12-21 20:59:59 UTC
Created attachment 56271 [details] [review]
Make one no_focus_window per screen
Comment 8 Elijah Newren 2005-12-22 06:39:04 UTC
Um, my explanation in comment 6 isn't very clear, plus I copy & pasted the wrong lines of code.  The right ones are the ones immediately following what I posted above, namely:
  /* else round-trip to server */
  if (screen == NULL)
    screen = meta_display_screen_for_xwindow (display,
                                              event->xany.window);
The basic idea is that the keybindings go to the currently focused window, metacity intercepts global keybindings when sent to any window, then metacity figures out which screen the focused window was located on, and then it has the global keybinding operate on that screen.
Comment 9 Havoc Pennington 2005-12-27 22:17:47 UTC
The patch looks fine, though I wonder if it will still have a couple issues.

Is the user-expected behavior that keybindings operate on the screen with the pointer, or the screen with the currently-focused window, or ... ?
Does this patch keep the active no focus window in sync with that "screen focus"?

There's an existing concept of "current xinerama" ... maybe should just use that?
Comment 10 Elijah Newren 2005-12-28 06:26:40 UTC
Yeah, there's definitely a couple issues in addition to the one this patch addresses; bug 324772 is a tracker bug for them.  In particular, you seem to be getting at bug 319348.  I believe that the user-expected behavior is that keybindings operate on the screen with the pointer, but since I've only had a dual screen setup for about a week and I'm one of those weirdo mouse focus users I may not yet have an accurate understanding of the general use case.  If my preliminary understanding is correct, then I agree that something similar to the "current xinerama" concept would be useful.  However, unlike the xinerama case we may not need to do a round-trip everytime we want to determine this setting, since separate screens means that EnterNotify events will likely provide the necessary information.

Anyway, since you had no objections to the patch (and since it fixes what is by far the worst issue, and I believe it will be used in the fix for the other issues once I/we understand them better), I went ahead and committed.  I'll link to these extra comments from the other bug.  Scream if I misunderstood and I should revert this patch for now.  ;-)

2005-12-27  Elijah Newren  <newren@gmail.com>

	Make the workspace switcher work with dual-head (non-xinerama)
	setups.  Fixes #319423.
Comment 11 Elijah Newren 2006-01-05 23:59:38 UTC
*** Bug 325929 has been marked as a duplicate of this bug. ***
Comment 12 Elijah Newren 2006-03-25 15:25:55 UTC
*** Bug 328643 has been marked as a duplicate of this bug. ***
Comment 13 Karl Wagener 2006-03-25 20:06:45 UTC
I love you guys!!
Sleep well.
Comment 14 Elijah Newren 2007-08-12 16:39:17 UTC
*** Bug 464971 has been marked as a duplicate of this bug. ***