I have appended the same report to bug 320423 since I thought it is the same issue. I note it here because the two reports are surely related. In my case, however, mouse clicks are also impaired which makes me think that kwin is the right component to report against and not kdelibs. Abstract ------------ In KDE4 times, there was a QT bug messing up shortcuts when a non-standard (russian, neo, etc.) keyboard layout or variant was set as the default layout either via xorg.conf or in the System Setting of KDE4. This is documented in the KDE as well as in the QT bug tracker [1,2], and was fixed at some point for QT4 and KDE4. According to [1], the issue reappeared for Plasma5 . My observation on Plasma5 is, than not only the shortcuts are affected, but also mouse clicks fall through, at least for Java applications using the Abstract Window Toolkit [3]. The Java application in question is Matlab (R2015a), and since it is closed source (sorry, not my choice), I rely on information from the java console (jconsole). Setup and configuration -------------------------------- I experience the issue running Plasma 5 a MacBook Pro using the Intel Integrated Graphics Controller of its i7 cpu. My graphics setup is 20-intel.conf ------------------ Section "Device" Identifier "Intel Graphics" Driver "intel" Option "TearFree" "true" EndSection So I am using the standard open source "intel" driver. My keyboard setup on X11 level is 20-keyboard.conf ----------------------- Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de" Option "XkbModel" "pc104" EndSection I use the German keyboard layout "de" here. I would love to configure neo [4,5], but unfortunately, this kills shortcuts and clicks. In the System Setting of Plasma 5 under "Input Devices" I configure two layouts. Both are German, the first in the default variant "de", the second in the variant "neo". I leave the System Setting of KDE 4 alone. The situation ----------------- To make the naming of shortcuts clear I prepend the active variant "de" or "neo" to the shortcut. This is de[Strg+c] is copy in the sense of the "de" variant, and the actual keys pressed coincide with the labeling on the physical keyboard. In contrary neo:[Strg+c] refers to copy in the frame of the neo variant, but the actual keys pressed with respect to the physical keyboard are Strg+r. The setup described above leads to the following situation. --- Keyboard shortcuts ---- ----------------------------------- ------ KF5 based applications In KF5 based applications like KWrite, keyboard shortcuts follow the layout variant. This is, neo[Strg+x] cuts out text, and de[Strg+x] also cuts out text when the respective layout is activated. Interestingly, if "neo" is active, and I hit neo[Strg+ö] which is de[Strg+x], text is also cut out. So, the shortcut is interpreted as if "de" would be active. However, if I hit neo[Strg+p] which is de[Strg+v], text is not inserted as you might expect, but the print dialog opens. This is because neo[Strg+p] is the shortcut for print. So, a shortcut configured in the frame of the currently active variant "neo" takes precedence over whatever is configured in the frame of an inactive variant. This is already strange by itself, and I would considered it a bug. ------ KDE 4 applications In applications still based on KDE4 such as Dolphin, only the shortcuts in the frame of the "de" variant work. This makes perfect sense, since X11 only know about "de" and the System Setting of KDE 4 are not changed. Here, I would love so see, that KDE 4 applications follow whatever is configured for Plasma5 to avoid inconsistencies. The usual user simply does not care which libraries an application uses, and hence does not want to configure the same things twice for different applications. --- Mouse clicks ---------------------- As already mentioned in the Abstract, I use Matlab which is a Java application. The situation is a little fuzzy in detail, but the general picture is, that 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 only happens, if the non-standard keyboard layout variant "neo" is active. To this end, it is not important if it is the primary or the non- primary variant. If I configure "neo" as the only variant on X11 level, keyboard and clicks are broken. If I configure "de" as the only variant in X11 and "de" as primary and "neo" as secondary variant in the Plasma5 System Setting, clicks are broken as soon as "neo" is active, and work all right is "de" is active. Information I can provide --------------------------------- I would be glad to help the situation by providing further information. I would categorize myself as an advanced user. So you can ask me for all information I can gather on the command line, system logs, java console, etc. I fear, however, that I can not offer to compile e.g. kwin in order to test patches; therefore, I am simply lacking the time. I run Arch Linux, and as far is I know, they strip their binaries. Debugging information is therefore of limited use. If there is really the need, irrespective of what I just say, you can ask me to compile, and I see what I can do. References --------------- [1] https://bugs.kde.org/show_bug.cgi?id=320423 [2] https://bugreports.qt.io/browse/QTBUG-32908 [3] https://en.wikipedia.org/wiki/Abstract_Window_Toolkit [4] http://www.neo-layout.org/ [5] http://en.wikipedia.org/wiki/Keyboard_layout#Neo Reproducible: Always Steps to Reproduce: 1. Install Plasma 5 2. Setup a non-standard keyboard layout (neo, russian) 3. Find the shorcuts brocken 4. Find clicks missing their target window for java apps Actual Results: Please see the report above. Expected Results: Shortcuts and mouse clicks should work.
> 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.