157219 2008-02-05 17:01:18 +0000 Unpredictable focus when switching desktops on a multi-head system 2024-05-14 21:38:19 +0000 1 1 4 Plasma kwin multi-screen unspecified Gentoo Packages Linux RESOLVED UNMAINTAINED https://bugs.kde.org/show_bug.cgi?id=324782 NOR normal --- 1 bernds_cb1 kwin-bugs-null cpigat242 johnny kde kde non7top postix riaasm sogerc1 0 oldest_to_newest 577902 0 bernds_cb1 2008-02-05 17:01:19 +0000 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. 577904 1 23431 bernds_cb1 2008-02-05 17:02:07 +0000 Created attachment 23431 A patch which fixes the problem on my system. 577914 2 l.lunak 2008-02-05 17:40:34 +0000 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. 578006 3 bernds_cb1 2008-02-05 23:27:31 +0000 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. 578007 4 bernds_cb1 2008-02-05 23:28:18 +0000 BTW, what doesn't look right about the patch? 578432 5 l.lunak 2008-02-07 15:28:42 +0000 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. 578698 6 bernds_cb1 2008-02-08 15:44:16 +0000 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. 579598 7 l.lunak 2008-02-11 13:17:40 +0000 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 579600 8 l.lunak 2008-02-11 13:18:45 +0000 Because of the imminent 3.5.9 tagging I've committed a hack for the multihead case that probably will avoid the problem. 579616 9 bernds_cb1 2008-02-11 14:19:15 +0000 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. 593949 10 magnus 2008-04-13 15:17:21 +0000 Just to add to this... This annoying behaviour seems to be present in 4.0.3 as well. 1197712 11 non7top 2011-12-10 21:18:10 +0000 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. 1197750 12 thomas.luebking 2011-12-10 23:56:52 +0000 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) 1237943 13 riaasm 2012-03-19 04:22:46 +0000 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. 1238634 14 thomas.luebking 2012-03-21 00:43:12 +0000 *** Bug 134677 has been marked as a duplicate of this bug. *** 1317106 15 thomas.luebking 2012-11-20 23:44:50 +0000 bump to self to look at when checking for the other bug next time 2319624 16 kde 2024-05-14 21:38:19 +0000 Multihead is no longer supported 23431 2008-02-05 17:02:07 +0000 2008-02-05 17:02:07 +0000 A patch which fixes the problem on my system. kwin.diff text/plain 377 bernds_cb1 LS0tIC4va3dpbi93b3Jrc3BhY2UuY3BwfgkyMDA3LTEwLTA4IDExOjUxOjMyLjAwMDAwMDAwMCAr MDIwMAorKysgLi9rd2luL3dvcmtzcGFjZS5jcHAJMjAwOC0wMi0wNSAxNTo0NzowOC4wMDAwMDAw MDAgKzAxMDAKQEAgLTExODgsNiArMTE4OCw4IEBACiAgICAgICAgIHJldHVybiBmYWxzZTsKIAog ICAgIGNsb3NlQWN0aXZlUG9wdXAoKTsKKyAgICBmb2N1c1RvTnVsbCgpOworCiAgICAgKytibG9j a19mb2N1czsKIC8vIFRPRE8gICAgUV9BU1NFUlQoIGJsb2NrX3N0YWNraW5nX3VwZGF0ZXMgPT0g MCApOyAvLyBtYWtlIHN1cmUgc3RhY2tpbmdfb3JkZXIgaXMgdXAgdG8gZGF0ZQogICAgIFN0YWNr aW5nVXBkYXRlc0Jsb2NrZXIgYmxvY2tlciggdGhpcyApOwo=