Discussion began on BUG 256242 (See https://bugs.kde.org/show_bug.cgi?id=256242#c117), but wanted to stop bloating that old report. Briefly, in a dual-head setup on Linux, where two X screens are running and KDE_MULTIHEAD=true, closing a window on one X DISPLAY will cause kwin to activate a window (or the desktop if no window is open), on the opposite X display. Attaching detailed debug information here, generated in a tmux session, controlled over ssh from my laptop. Reproducible: Always Steps to Reproduce: Hardware: Two graphics cards, each connected to its own monitor (well, one's a TV over HDMI, other a monitor over DVI). Customise files in /etc/X11/x.org.conf.d/, to include two sections each of Monitor, Device and Screen. The active ServerLayout has two Screen's. Steps taken to debug kwin -------------- * Build and install debug version of kwin. (cmake -DCMAKE_BUILD_TYPE=Debug ...) * Start a tmux session on DISPLAY :0.0 * In a tmux window, run `kwin --replace` * Open new tmux window for gdb * Attach to same tmux session from laptop over ssh. * Setup some windows on DISPLAY :0.0 i. empty konsole:: ;WMCLASS: "konsole" : "konsole" ;Caption: "albl500 : bash â Konsole <2>â" ii. dolphin:: ;WMCLASS: "dolphin" : "dolphin" ;Caption: "albl500 â Dolphin" ' * Keep these windows focused. Closing dolphin (which is active,) should then raise konsole Bug traces have been generated under a couple of conditions. I will attach (to preserve monospaced characters) as a plain text file, after submitting. Worth mentioning a couple of patches applied to the code, which were suggested in BugId#256242 to help with multihead setups. Specifically, in comments:- - https://bugs.kde.org/show_bug.cgi?id=256242#c115 - https://bugs.kde.org/show_bug.cgi?id=256242#c119 Comment #115 patch is a bugfix; Comment #119 patch prints message to console running `kwin --replace`.
Created attachment 82271 [details] Debugging work on multihead task switching
events.cpp ~ line 290 if (focus == None || focus == PointerRoot) { //kWarning( 1212 ) << "X focus set to None/PointerRoot, reseting focus" ; Client *c = mostRecentlyActivatedClient(); if (c != NULL) requestFocus(c, true); else if (activateNextClient(NULL)) ; // ok, activated else focusToNull(); } I assume you're ending up here when/before this happens and preventing this block (* that is NOT USABLE FIX!) would also prevent the unwanted focus switch? * - if (focus == None || focus == PointerRoot) { + if (false /*focus == None || focus == PointerRoot*/) {
*** Bug 344671 has been marked as a duplicate of this bug. ***
Created attachment 95545 [details] patch attempt Patch, should apply to 5.4 I briefly tried it, but guess Martin would like to have it confirmed by somebody who actually uses zaphod multihead on a regular base
Created attachment 95546 [details] base patch patch for bug #348935 that's likely required to apply the actual patch cleanly; sorry.
I went back to clean sources and applied the patches. It is, however, throwing errors like this from the "isOnCurrentHead" function: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 14659, resource id: 1, major code: 14 (GetGeometry), minor code: 0 which I suppose is sort of lucky because previous versions of the source just crashed there. As I explained here: https://bugs.kde.org/show_bug.cgi?id=344671#c9 the "Xcb::CurrentInput currentInput" call can have three types of return; XCB_WINDOW_NONE(0), XCB_INPUT_FOCUS_POINTER_ROOT(1) or the actual Window ID. Your code only handles XCB_WINDOW_NONE and the actual Window ID. If you attempt to execute the "Xcb::WindowGeometry geometry(currentInput.window())" line when "currentInput.window()" is "1" (i.e. XCB_INPUT_FOCUS_POINTER_ROOT), the result is undefined at best and a crash at worst. Ironically, if you had changed the window revert setting to "XCB_INPUT_FOCUS_NONE" as you threatened here: https://bugs.kde.org/show_bug.cgi?id=344671#c18 then the code would probably have run without errors although had you ever changed it back to "XCB_INPUT_FOCUS_POINTER_ROOT", then your new patch would have broken too. I look forward to testing your corrected patch.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.