Bug 157219 - Unpredictable focus when switching desktops on a multi-head system
Summary: Unpredictable focus when switching desktops on a multi-head system
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 134677 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-05 17:01 UTC by Bernd Schmidt
Modified: 2024-05-14 21:38 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
A patch which fixes the problem on my system. (377 bytes, patch)
2008-02-05 17:02 UTC, Bernd Schmidt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Schmidt 2008-02-05 17:01:19 UTC
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.
Comment 1 Bernd Schmidt 2008-02-05 17:02:07 UTC
Created attachment 23431 [details]
A patch which fixes the problem on my system.
Comment 2 Lubos Lunak 2008-02-05 17:40:34 UTC
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.
Comment 3 Bernd Schmidt 2008-02-05 23:27:31 UTC
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.
Comment 4 Bernd Schmidt 2008-02-05 23:28:18 UTC
BTW, what doesn't look right about the patch?
Comment 5 Lubos Lunak 2008-02-07 15:28:42 UTC
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.
Comment 6 Bernd Schmidt 2008-02-08 15:44:16 UTC
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.
Comment 7 Lubos Lunak 2008-02-11 13:17:40 UTC
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
Comment 8 Lubos Lunak 2008-02-11 13:18:45 UTC
Because of the imminent 3.5.9 tagging I've committed a hack for the multihead case that probably will avoid the problem.
Comment 9 Bernd Schmidt 2008-02-11 14:19:15 UTC
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.
Comment 10 Magnus Johansson 2008-04-13 15:17:21 UTC
Just to add to this...

This annoying behaviour seems to be present in 4.0.3 as well.
Comment 11 Vladimir Berezhnoy 2011-12-10 21:18:10 UTC
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.
Comment 12 Thomas Lübking 2011-12-10 23:56:52 UTC
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)
Comment 13 riaasm 2012-03-19 04:22:46 UTC
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.
Comment 14 Thomas Lübking 2012-03-21 00:43:12 UTC
*** Bug 134677 has been marked as a duplicate of this bug. ***
Comment 15 Thomas Lübking 2012-11-20 23:44:50 UTC
bump to self to look at when checking for the other bug next time
Comment 16 David Edmundson 2024-05-14 21:38:19 UTC
Multihead is no longer supported