| Summary: | Unpredictable focus when switching desktops on a multi-head system | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Bernd Schmidt <bernds_cb1> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | cpigat242, johnny, kde, kde, non7top, postix, riaasm, sogerc1 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=324782 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | A patch which fixes the problem on my system. | ||
|
Description
Bernd Schmidt
2008-02-05 17:01:19 UTC
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 |