Bug 347964

> mouse clicks are also impaired which makes me think that kwin is the right component
Rarely. There's no input redirection in X11. KWin casually blocks mouse input resp. does nor does not forward and/or replay them, but it can not[1] and does not redirect mouse clicks from one window to another.

>  I use Matlab which is a Java application.
... m(
> if there are more than two Matlab windows open, e.g. the editor and two windows for plots, 
> the clicks fall through the window which is clicked.

This is "impossible":
Mouseclicks do not "fall through".
Unless the mouse is grabbed by one client (very much possible cause here) the X11 server passes them directly to the topmost input client.
The client process receives them and *may* internally processes them for the wrong window.

Notably:
=> If this does *only* happen with matlab, you can be very sure that it's a bug in matlab.
=> If it does *only* happen in Java clients, you can be very sure that it's a bug in java - what would actually not be very surprising (*sigh*)

You can run "xev -id <WID of topmost matlab client> -event mouse"
To obtain <WID of topmost matlab client>, simply query "xwininfo" (click the window when the cursor turns into '+')

Notably if you find that the window indeed receives the input event, but also if this can only be reproduced on a limited amount of clients, this bug is INVALID.

---
[1] Yes, we could block them and utilize the xtest extension to fake them otherwhere, but that's not the case. Nor do we send mouse events and most clients don't accept synthetic events from outside anyway.

(In reply to Thomas Lübking from comment #1)
> > mouse clicks are also impaired which makes me think that kwin is the right component
> Rarely. There's no input redirection in X11. KWin casually blocks mouse
> input resp. does nor does not forward and/or replay them, but it can not[1]
> and does not redirect mouse clicks from one window to another.
> 
> >  I use Matlab which is a Java application.
> ... m(
> > if there are more than two Matlab windows open, e.g. the editor and two windows for plots, 
> > the clicks fall through the window which is clicked.
> 
> This is "impossible":
> Mouseclicks do not "fall through".
> Unless the mouse is grabbed by one client (very much possible cause here)
> the X11 server passes them directly to the topmost input client.
> The client process receives them and *may* internally processes them for the
> wrong window.
> 
> Notably:
> => If this does *only* happen with matlab, you can be very sure that it's a
> bug in matlab.
> => If it does *only* happen in Java clients, you can be very sure that it's
> a bug in java - what would actually not be very surprising (*sigh*)

First, thanks for your quick response. About your last two points. I only observe it with Matlab. I also tried JabRef (java, but different toolkit) and everything works fine. However, I only experience the issue in KDE with non-default keyboard layout. Under lxqt, which also uses QT and frameworks, everything works irrespective of the keyboard layout chosen. So, while the cause for the error might not be in kde/kwin/kdelibs, others are not hit by it. Please don't read this as an insult, I just want to put out all the information I have.

> 
> You can run "xev -id <WID of topmost matlab client> -event mouse"
> To obtain <WID of topmost matlab client>, simply query "xwininfo" (click the
> window when the cursor turns into '+')

I put up a test-scenario consisting of three windows. The Matlab main window, the Matlab Command Window, and a Matlab figure window, Figure1. I provide screenshots and xev output.

=> Initial situation (screenshot clickFigure.jpeg)
- The focus is on the figure windows Figure 1
- Figure one is over the main window (MATLAB) which is over the Command Window
- I click on the surface of Figure 1 as indicated on the screenshot.

=> Resutling situation (screenshot clickedFigure.jpeg)
- The Command Window is raised all the way to the top
- The main window stays below Figure 1

=> xev output for Figure 1
LeaveNotify event, serial 18, synthetic NO, window 0x66000fa,
    root 0xc5, subw 0x66000fc, time 3403299, (31,70), root:(722,610),
    mode NotifyGrab, detail NotifyVirtual, same_screen YES,
    focus NO, state 8448

EnterNotify event, serial 18, synthetic NO, window 0x66000fa,
    root 0xc5, subw 0x66000fc, time 3403358, (31,70), root:(722,610),
    mode NotifyUngrab, detail NotifyVirtual, same_screen YES,
    focus NO, state 8448

LeaveNotify event, serial 18, synthetic NO, window 0x66000fa,
    root 0xc5, subw 0x66000fc, time 3403500, (31,70), root:(722,610),
    mode NotifyUngrab, detail NotifyNonlinearVirtual, same_screen YES,
    focus NO, state 8192

=>xev output for the Command Window
Command window event
EnterNotify event, serial 18, synthetic NO, window 0x66000b6,
    root 0xc5, subw 0x66000b8, time 3403500, (82,160), root:(722,610),
    mode NotifyUngrab, detail NotifyNonlinearVirtual, same_screen YES,
    focus NO, state 8192

=> xev output for the main window
No event was reported for the main window


So, I guess, the click reaches the window, but the routing of the click is wrong. In the same situation, after selecting keyboard layout "de" using the KDE layout selector, everything works as expected. I can not understand, why the keyboard layout should influence the routing withing Matlab. If there is a possible reason for this, I would be more than glad to read about it.

> 
> Notably if you find that the window indeed receives the input event, but
> also if this can only be reproduced on a limited amount of clients, this bug
> is INVALID.

Well, I only have one machine. I have no idea how I should proof that the bug accours on an unlimited number of clients.

Thanks for your time!


> 
> ---
> [1] Yes, we could block them and utilize the xtest extension to fake them
> otherwhere, but that's not the case. Nor do we send mouse events and most
> clients don't accept synthetic events from outside anyway.

(In reply to Wolfgang Mader from comment #2)

> and everything works fine. However, I only experience the issue in KDE with
> non-default keyboard layout. Under lxqt, which also uses QT and frameworks,
> everything works irrespective of the keyboard layout chosen.

I've not the least idea how the keyboard layout could come into this, but otherwise, (some) java clients are rather picky about focus handling, see bug #347153

I could imagine that matlab unconditionally processes mouse events as if they occured on the window which it thinks should now have the focus/be active - but that doesn't explain the keyboard layout condition requirement.

For the keyboard layout, I could assume that the modifiers get confused (eg. Matlab believes control is pressed while it's actually numlock and handles mousepresses as ctrl+mouse) - but that doesn't explain the KDE requirement.

To check for KWin relevance (direct or indirect) in the mouseclick issue:
lxqt will likely run openbox as WM, so just call "openbox --replace &" in a Plasma session w/ neo layout and see what happens.
If it's gone, my next best guess would be bug #347153 w/ the keyboard layout being a red herring in this context. (5.3.1 should be released about next week)

> provide screenshots and xev output.
I assume your screenshot attachments were filtered out by bugzilla.
 
> Well, I only have one machine. I have no idea how I should proof that the
> bug accours on an unlimited number of clients.

Hehe - sorry.
"Client", from a WM perspective, is the process that provides a window.
As you mentioned: matlab seems the only client to expose this weird behavior.

In case the problem is gone w/ "openbox --replace &", please attach the output of "xwininfo -all" and "xprop" for all three windows.

Created attachment 92761 [details]
Situation after the mouse click took place

Created attachment 92762 [details]
Situation before the mouse click

(In reply to Thomas Lübking from comment #3)
> (In reply to Wolfgang Mader from comment #2)
> 
> > and everything works fine. However, I only experience the issue in KDE with
> > non-default keyboard layout. Under lxqt, which also uses QT and frameworks,
> > everything works irrespective of the keyboard layout chosen.
> 
> I've not the least idea how the keyboard layout could come into this, but
> otherwise, (some) java clients are rather picky about focus handling, see
> bug #347153
> 
> I could imagine that matlab unconditionally processes mouse events as if
> they occured on the window which it thinks should now have the focus/be
> active - but that doesn't explain the keyboard layout condition requirement.
> 
> For the keyboard layout, I could assume that the modifiers get confused (eg.
> Matlab believes control is pressed while it's actually numlock and handles
> mousepresses as ctrl+mouse) - but that doesn't explain the KDE requirement.
> 
> To check for KWin relevance (direct or indirect) in the mouseclick issue:
> lxqt will likely run openbox as WM, so just call "openbox --replace &" in a
> Plasma session w/ neo layout and see what happens.
> If it's gone, my next best guess would be bug #347153 w/ the keyboard layout
> being a red herring in this context. (5.3.1 should be released about next
> week)

Replacing kwin with openbox does not change the situation. I guess, this takes kwin off the hook. Thanks for your help! Since shortcuts are also not working, something is sure wrong somewhere. Should I turn to kdelibs next?

> 
> > provide screenshots and xev output.
> I assume your screenshot attachments were filtered out by bugzilla.
>  
> > Well, I only have one machine. I have no idea how I should proof that the
> > bug accours on an unlimited number of clients.
> 
> Hehe - sorry.
> "Client", from a WM perspective, is the process that provides a window.
> As you mentioned: matlab seems the only client to expose this weird behavior.
> 
> In case the problem is gone w/ "openbox --replace &", please attach the
> output of "xwininfo -all" and "xprop" for all three windows.

(In reply to Wolfgang Mader from comment #6)

> Replacing kwin with openbox does not change the situation. I guess, this
> takes kwin off the hook. Thanks for your help! Since shortcuts are also not
> working, something is sure wrong somewhere. Should I turn to kdelibs next?

It's unlikely a bug in kdelibs resp. any frameworks component: the only affected client doesn't link any kde/Qt libs (I assume)

Assuming the bug is related to keyboard symbol resolution and *not* in matlab, I'd blame kglobalaccel => try to kill it. ("pkill kglobalaccel5")
It's "normal" that global shortcuts (incl. eg. Alt+Tab) won't work until you restart it.

About the local shortcuts (ctrl+x etc.) that should be a bug in Qt5 - you may want to try whether they work in any "plain" Qt5 client.

If the same plain Qt5 client has this issue under KDE but not under lxqt, it could be in the platform plugin, try

KDE_FULL_SESSION=  KDE_SESSION_VERSION=  XDG_CURRENT_DESKTOP= XDG_SESSION_DESKTOP=  /path/to/qt5-app

(ie. unset all those vars temporarily)

If it's not in the platform plugin and not in kglobalaccel, I'm a bit lost
Did you check whether the output of
    setxkbmap -print
is still valid?

(In reply to Thomas Lübking from comment #7)
> (In reply to Wolfgang Mader from comment #6)
> 
> > Replacing kwin with openbox does not change the situation. I guess, this
> > takes kwin off the hook. Thanks for your help! Since shortcuts are also not
> > working, something is sure wrong somewhere. Should I turn to kdelibs next?
> 
> It's unlikely a bug in kdelibs resp. any frameworks component: the only
> affected client doesn't link any kde/Qt libs (I assume)
> 
> Assuming the bug is related to keyboard symbol resolution and *not* in
> matlab, I'd blame kglobalaccel => try to kill it. ("pkill kglobalaccel5")
> It's "normal" that global shortcuts (incl. eg. Alt+Tab) won't work until you
> restart it.

I killed kglobalaccel5 properly (global shortcuts were no longer working). This had _no_ effect on missed clicks in Matlab _and_ had _no_ effect on the local shortcuts. For the local shortcuts, I used kwrite, which is qt5/frameworks only. No dependency to qt4 or kde4libs. The shortcuts for kwrite work as expected under lxqt, but they don't under plasma5, w/ or w/o kglobalaccel5 running. May I please ask if some  can set up a second keyboard layout in the kde system setting (screenshot attached) and test if this issue is present only on my machine. This would be great!

> 
> About the local shortcuts (ctrl+x etc.) that should be a bug in Qt5 - you
> may want to try whether they work in any "plain" Qt5 client.
> 
> If the same plain Qt5 client has this issue under KDE but not under lxqt, it
> could be in the platform plugin, try
> 
> KDE_FULL_SESSION=  KDE_SESSION_VERSION=  XDG_CURRENT_DESKTOP=
> XDG_SESSION_DESKTOP=  /path/to/qt5-app

To avoid any missunderstanding, here is what I executed on the command line 
KDE_FULL_SESSION=  KDE_SESSION_VERSION=  XDG_CURRENT_DESKTOP=  XDG_SESSION_DESKTOP=  usr/bin/kwrite

The isse with the shorcuts remained.

Again, thanks for all the input!

> 
> (ie. unset all those vars temporarily)
> 
> If it's not in the platform plugin and not in kglobalaccel, I'm a bit lost
> Did you check whether the output of
>     setxkbmap -print
> is still valid?

Created attachment 92825 [details]
Keyboard system setting: Hardware

Created attachment 92826 [details]
Keyboard system setting: Layout

a) I can not advise anyone to try that - most stupid idea I ever had. 105 keys an no idea what they do...

b) That's the neo2 layout which has apparently a "xvlcwk" layout

c) local shortcuts in kwrite/kf5 work "as expected" - "ctrl+w" (qwertz HW -> logical "ctrl+v") pastes (qt5.4.1, kf5.11.0)

d) first time I read that <lots of swearing> keyboard daemon is invoked, I had assumed the plain config from xorg.conf was in control?
=> "kcmshell5 kded", disable and stop the keyboard daemon.
Also disable keyboard layouts in the keyboard kcm.
Log out/in, see what happens.

It's probably not a surprise that you get different results on other DEs, since the keyboard is configured completely differently. (

e) the primary layout in that screenshot is de, not neo2 - why do you assume neo2 is active?
Checked "setxkbmap -print"?

Killing kglobalccal5 was a wild guess on what might cause confusion on mouseclicks in matlab - it had no expectable impact on local shortcuts.

(In reply to Thomas Lübking from comment #11)
> a) I can not advise anyone to try that - most stupid idea I ever had. 105
> keys an no idea what they do...

Sorry, didn't thought about that side effect. Thanks for trying!

> 
> b) That's the neo2 layout which has apparently a "xvlcwk" layout

Thats correct.

> 
> c) local shortcuts in kwrite/kf5 work "as expected" - "ctrl+w" (qwertz HW ->
> logical "ctrl+v") pastes (qt5.4.1, kf5.11.0)
> 
> d) first time I read that <lots of swearing> keyboard daemon is invoked, I
> had assumed the plain config from xorg.conf was in control?
> => "kcmshell5 kded", disable and stop the keyboard daemon.
> Also disable keyboard layouts in the keyboard kcm.
> Log out/in, see what happens.

I did disables the keyboard deamon and the layout switching and configured the layouts in on x11 level

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option  "XkbLayout" "de,de"         
        Option  "XkbVariant" "basic,neo"    
        Option  "XkbOptions" "grp:shifts_toggle" 
        Option "XkbModel" "pc104"
EndSection

To avoid further bad language habbits, I attached srceenshots of the interesting kcm dialogs. Shortcut behaviour stays as described earlier. Lxqt works as expected, Plasma doesn't.

> 
> It's probably not a surprise that you get different results on other DEs,
> since the keyboard is configured completely differently. (
> 
> e) the primary layout in that screenshot is de, not neo2 - why do you assume
> neo2 is active?

Well, hitting the keyboard spits out characters according to the neo2 layout + I chose neo in the layout switcher of the which resides in the system tray.

> Checked "setxkbmap -print"?

This is not really the output you are looking for, but the output of the current x11-only config.

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwertz)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+caps(caps_lock):2+misc(assign_shift_left_action):2+level5(level5_lock):2"     };
        xkb_symbols   { include "pc+de(basic)+de(neo):2+inet(evdev)+group(shifts_toggle)"       };
        xkb_geometry  { include "pc(pc104)"     };
};
> 
> Killing kglobalccal5 was a wild guess on what might cause confusion on
> mouseclicks in matlab - it had no expectable impact on local shortcuts.

I figured, but I did not want to miss a combination of your sugestions.


Thanks again! I always try to include all the information which seems relevant for me. Sorry for the confusion with respect to the keyboard deamon.

Created attachment 92853 [details]
Keyboard deamon disabled

Created attachment 92854 [details]
Keyboard system setting: Hardware

Created attachment 92855 [details]
Keyboard system setting: Layout disabled

Hi, I have similar issues with MATLAB.

The behaviour I see is this:
- If only one MATLAB window is open, everything works fine.
- If two windows are open:

Situation 1:
1. The focus is on the MATLAB main window
2. If I click on the TITLE BAR of the MATLAB figure windows, the matlab figure gain the kwin-focus
3. If I click back on the matlab main window I cannot type
4. If now I click on the matlab figure window, not in the title bar but into the window (where matlab has "control") then the matlab main window blink and if I click back to it I can type

Situation 2:
If I repeat the previous process, but on point 2 I click into the figure window, everything works fine

The fact that this may be related to the keyboard layout doesn't surprise me, because I had similar issues with another MATLAB bug:

See this (and all the references inside)
https://bugs.kde.org/show_bug.cgi?id=345386

Nice to see that I am not the only one. Question is what can be done about this bug. I moved from Matlab to R, but this can hardly be seen as a solution. :)

I'm not completely sure the bug is the same tough. Because the problem I have with window focusing happens also when I configure a single layout.

What you can do, at least to solve the mouse click problem, is to create a script to change layout, that also switches the order of the keyboard layout in:
./.kde4/share/config/kxkbrc (or in the corresponfing KDE5 config file)
so that the layout in use is always the first.

Weird focus behavior in java clients could be covered by https://git.reviewboard.kde.org/r/123639/ - should be fixed in 5.3.1 and affected all KF5 versions of KWin before.

Other WMs may not support this focus management at all (leading to similar problems)

(In reply to Wolfgang Mader from comment #17)
> Question is what can be done about this bug.
Ask matlab to abort java? :-P

If¹ this has anything to do with java's handling of the takefocus protocol, you *might* be able to workaround it by setting up a window rule for matlab to forcefully accept the window focus.

[1] Output of "xwininfo" and "xprop" on the involved windows?

(In reply to Thomas Lübking from comment #19)
> Weird focus behavior in java clients could be covered by
> https://git.reviewboard.kde.org/r/123639/ - should be fixed in 5.3.1 and
> affected all KF5 versions of KWin before.
> 
> Other WMs may not support this focus management at all (leading to similar
> problems)

I am using
kwin_x11 --version 
-> kwin 5.3.2

If I read this correctly, your fix should be in effect already. My issue, howeve, remains.

Anyway, thanks for your work!

Thanks for the info. They should definitely drop java. Would be nice a MATLAB in Qt... a dream.

(In reply to Simone Gaiarin from comment #22)
> Thanks for the info. They should definitely drop java. Would be nice a
> MATLAB in Qt... a dream.

In deed... but this will never happen I fear.

I've noticed when using a non standard keyboard layout configured in KDE that the 'window shortcut' input isn't aware of the layout and is using the us layout instead.

That's https://bugs.kde.org/show_bug.cgi?id=350816 - unlikely related to this bug.

Might be related: With plasma kde-plasma/kwin 5.6.5-r1 CTRL-X does not reach the application when setting a lithauian keyboard (lv), but the copied text appears in klipper. This makes it pretty hard to use Emacs.

(In reply to Arne Babenhauserheide from comment #26)
> Might be related: With plasma kde-plasma/kwin 5.6.5-r1 CTRL-X does not reach
> the application when setting a lithauian keyboard (lv), but the copied text
> appears in klipper. This makes it pretty hard to use Emacs.

I now found that I can trigger CTRL-x in emacs with CTRL-SHIFT-x.

Overall this bug report turned into a collection of "weird issues with matlab" which means it's difficult to say what now this bug is about.

The initial reported issue is clearly not a bug in KWin as KWin is not responsible at all for mouse pointer passing. Given that I set the bug to INVALID.

For the other matlab related issues: if it is window management related, please report a new bug report. And please only one issue per bug report.