Version: (using KDE 3.5.8) Installed from: Gentoo Packages Compiler: gcc-4.1 gentoo's 4.1 OS: Linux I have two monitors, which show X displays :0.0 and :0.1. There are two instances of kwin running, apparently handling the displays separately. Each of the displays has 12 virtual desktops with a konsole and possibly other windows on each of them. When switching desktops with Ctrl-F1..Ctrl-F12, the focus often (but unpredictably) switches to the other monitor, rather than a window on the desktop you've just switched to getting the focus. This is highly annoying; it means you can't quickly look through all virtual desktops on one screen by hitting Ctrl-F1, Ctrl-F2, etc. successively, because at some point the keypresses go to the wrong screen. I don't know exactly how focus is handled in X, especially with multiple monitors. I've looked at the code in kwin's workspace.cpp, and developed the following theory: Switching desktops is implemented by unmapping all windows from the current desktop, then mapping all windows on the new one. It appears that when there's more than one kwin running, they can fight for the right to focus a window. My theory is that when all windows from the previous desktop on one screen are unmapped (thus losing focus), the kwin running on the other screen tries to set the focus to one of the windows showing on its current desktop. Based on this, I've created a patch which just calls focusToNull before unmapping the windows in a desktop switch, and this seems to take care of the problem. I'll be attaching the patch once I'm out of this bugzilla wizard.
Created attachment 23431 [details] A patch which fixes the problem on my system.
The patch does not look right. Can you figure out where the focus changes come from? KWin on the inactive screen should not do anything at all when working with the active one. If you use e.g. 'kdDebug() << getenv("DISPLAY") << ":" << kdBacktrace();' in Workspace::requestFocus() (and possibly before all calls to XSetInputFocus() ), it should show where the unwanted activation comes from.
That's just giving me stuff like kwin: :0.1:[ 0: /usr/kde/3.5/lib/libkdecore.so.4(_Z11kdBacktracei+0x45) [0xb7b59255] ] which isn't very enlightening.
BTW, what doesn't look right about the patch?
You probably have things compiled without any debug support at all, kdBacktrace() works best with '-rdynamic' in CXXFLAGS and '-D__KDE_HAVE_GCC_VISIBILITY=0' in cmake flags. You may try that or some other ways like more debug outputs to find out where it comes from. As for comment #4, the patch moves the X focus where it should not be, even if temporarily, and I'd prefer to find the correct problem and fix it instead of just patching it over.
BTW, I forgot to mention in my previous posts that I'm using click-to-focus; that may or may not make a difference. I think I managed to capture the right backtrace. Sequence of events: I activated a a window on display :0.1, then hit one of the Ctrl-Fn keys to switch desktops. Desktops got switched on :0.1, but a window on display :0.0 got activated. The following backtrace came out of the kwin for display :0.0 in this instant: kwin: :0.0:[ 0: /local/src/kdelibs-3.5.8/kdecore/.libs/libkdecore.so.4.2.0(_Z11kdBacktracei+0x36) [0xb7e5e29e] 1: /local/src/kdelibs-3.5.8/kdecore/.libs/libkdecore.so.4.2.0(_Z11kdBacktracev+0x28) [0xb7e5e4ac] 2: /local/src/kdebase-3.5.8/kwin/./.libs/libkdeinit_kwin.so(_ZN12KWinInternal9Workspace12requestFocusEPNS_6ClientEb+0x24) [0xb7d2bbe6] 3: /local/src/kdebase-3.5.8/kwin/./.libs/libkdeinit_kwin.so(_ZN12KWinInternal9Workspace18activateNextClientEPNS_6ClientE+0x2cd) [0xb7d2bff3] 4: /local/src/kdebase-3.5.8/kwin/./.libs/libkdeinit_kwin.so(_ZN12KWinInternal9Workspace14workspaceEventEP7_XEvent+0xbb0) [0xb7d1c238] 5: /local/src/kdebase-3.5.8/kwin/./.libs/libkdeinit_kwin.so(_ZN12KWinInternal11Application14x11EventFilterEP7_XEvent+0x28) [0xb7d0cc56] 6: /usr/qt/3/lib/libqt-mt.so.3 [0x44393174] 7: /usr/qt/3/lib/libqt-mt.so.3(_ZN12QApplication15x11ProcessEventEP7_XEvent+0x228) [0x443a2a38] 8: /usr/qt/3/lib/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x4c1) [0x443b3b51] 9: /usr/qt/3/lib/libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0x50) [0x444193a0] 10: /usr/qt/3/lib/libqt-mt.so.3(_ZN10QEventLoop4execEv+0x26) [0x44419226] 11: /usr/qt/3/lib/libqt-mt.so.3(_ZN12QApplication4execEv+0x1f) [0x444027af] 12: /local/src/kdebase-3.5.8/kwin/./.libs/libkdeinit_kwin.so(kdemain+0x620) [0xb7d0da64] 13: lt-kwin [0x80486c6] 14: /lib/libc.so.6(__libc_start_main+0xe0) [0xb74889c0] 15: lt-kwin [0x8048621] ] As for the focus moving where it should not be - this happens anyway, as a side effect, when we unmap all windows from a virtual desktop, doesn't it? So the patch I proposed just moves it explicitly, earlier.
SVN commit 773568 by lunakl: Disable resetting focus from root window as it seems to cause focus problems with multihead for an unknown reason. CCBUG: 157219 M +2 -1 events.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=773568
Because of the imminent 3.5.9 tagging I've committed a hack for the multihead case that probably will avoid the problem.
This seems to work so far, with no ill effects. From an engineering point of view my earlier patch still seems preferrable to me, since it has the same behaviour on all systems and is therefore more testable.
Just to add to this... This annoying behaviour seems to be present in 4.0.3 as well.
This bug is still valid on 4.7.2. Steps to reproduce: 1. Launch yakuake on :0.0, may also open some more windows on :0.0 2. Focus some window on :0.0 3. Press yakuake hotkey, yakuake then opens as expected, press hotkey once more to hide yakuake 4. At this point focus jumps to second screen :0.1, while it should return to where it was befor yakuake got opened. I should note that some times 4 hapens only after repeating 3 second time in a row.
Still or again? The workaround from comment #7 is absent and indeed the other KWin instance recognizes a FocusIn on *its* rootWindow and so thinks it's time to activate something (in doubt a dummy) Since this is usually slight faster than the post-window-hiding stuff the kwin instance on the yakuake screen does, the other kwin wins. We must eg. figure which screen has the mouse and only act on it or avoid KWin2 getting rootwindow FocusIn's when KWin1 closes a client. Also see bug #256242 (and be aware that there's not much pace on multihead development - eg. i only actiavted it to check some bugs, didn't like it at all)
I think this problem might be the same as bug 237260 which is similar but with alt-tab. I described it in more detail in bug 274369 with a reproduction recipe which also seems to work when trying to look through your virtual desktops with Ctrl+F1 to Ctrl+F2 and so on.
*** Bug 134677 has been marked as a duplicate of this bug. ***
bump to self to look at when checking for the other bug next time
Multihead is no longer supported