Bug 371877

Summary: Support for keyboard_shortcuts_inhibit_unstable_v1 needed
Product: [Plasma] kwin Reporter: atmarx <amarx>
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: alex765, alexander.stehlik, bugseforuns, darinsmiller, kde, kkremitzki, marcushallett+linux, ndrzj1gbo, peter, sachzky, subdiff, thomas.pfeiffer
Priority: NOR Flags: vlad.zahorodnii: Wayland+
mgraesslin: X11+
mgraesslin: Usability+
Version: 5.8.2   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In: 5.20

Description atmarx 2016-10-31 02:47:08 UTC
When running a program that captures the keyboard to redirect to a remote device (virtualbox, remmina rdp connection, teamviewer), alt+{key} and meta+{key} combos aren't being properly ignored by the host.  Pressing just the meta key causes it to fire on both, but any key combo only seems to pass the modifier key (win+d will minimize all of my local windows, but if I switch back to an windows remmina session, the start menu is up -- meta key fired remotely, but no 'd')

I'm running the latest install of KDE Neon (27/10/16), after upgrading from Kubuntu 16.10 (so KDE 5.7.5, I believe) which did not exhibit this issue.

It's great the meta key now pops up the app launcher without any workarounds required, but if this is the cost... :(

I had originally posted this under plasmashell, but the devs said it sounded like a kwin issue.  Sorry if this is the wrong product/component for this issue.
Comment 1 Martin Flöser 2016-10-31 06:06:54 UTC
I do not fully understand the problem. What exactly does not work as you expect. Could you please follow the steps to reproduce:

1. I did this
2. then I pressed this
3. then that

Actual Result: the following happened

Expected Result: but I wanted that to happen.
Comment 2 atmarx 2016-10-31 10:13:42 UTC
Fair enough.

1. I launched a Virtualbox VM (or other program that captures the local keyboard -- TeamViewer, Remmina, etc)

2. In the guest session, I pressed alt+tab (or any other alt+{key} or meta+{key} combo).

Actual result: my host changes windows

Expected result: but I wanted to change windows (or trigger some other shortcut) in the VM (or remote session, etc).

It's like KDE is being grabby with the key combos instead of properly passing it along to the app that's supposed to have captured the keyboard.
Comment 3 Martin Flöser 2016-10-31 10:37:13 UTC
Sorry, but you also wrote about the "meta key" and menu opening? How is that related? So far your bug report is only about Alt+Tab which are normal global shortcuts? So how does the meta key play into that?
Comment 4 atmarx 2016-10-31 10:45:22 UTC
Same thing -- if I press the meta key by itself in the keyboard captured window, it launches the app launcher on the host _and_ the remote session / vm instead of only on the remote session / vm.

If I press a combo with meta {e.g. meta+D), my host shows the desktop, but the remote session / vm only receives a meta keypress -- not the whole shortcut.

I'm sorry if I'm being confusing -- this seems very straightforward to me.  Correct behavior was exhibited in KDE 5.7.5 that was bundled with Kubuntu 16.10.
Comment 5 atmarx 2016-10-31 10:54:08 UTC
I picked alt-tab as one example, but like I said in the original post, this appears to be true for any alt+{key} or meta+{key} combo.  Yes, they're global, but previous to installing KDE Neon, even global shortcuts were properly ignored by the host when an app was capturing the keyboard to send to a remote session / vm.
Comment 6 Martin Flöser 2016-10-31 12:09:06 UTC
So these are two very different issues:
* global shortcuts
* meta shortct

The global shortcuts can only trigger if no other window has grabbed the keyboard. If they trigger on the host, the client has failed to grab the keyboard. This is a problem with the application. If a global shortcut is intercepted, the application does not get the key event. This is expected behavior.

Concerning meta: the modifier only shortcuts are triggered independently from the grab state of applications. That is whenever meta is pressed - without any other key, it will fire on the host system.

I'm not sure whether it would be a good idea to change that. It's a well defined state of the system now that pressing meta will open the launcher - no matter which application is open or what it does. I see both advantages and disadvantages there. There are multiple such keys already which cannot be send to the guest system. E.g. ctrl+alt+F1 cannot be send. Normally VMs provide solutions for that.
Comment 7 atmarx 2016-10-31 12:39:40 UTC
I _guess_ it's possible that virtualbox, teamviewer, and remmina all somehow 'broke' at the same time, but considering the exact same versions work fine under KDE 5.7.5 (and under Unity, Xfce, etc), I'm more inclined to believe something changed in KDE between 5.7.5 and present.

If you're saying that this new behavior is 'by design', then I guess KDE is not designed for sysadmins who need to support other OSs remotely.
Comment 8 Martin Flöser 2016-10-31 13:00:32 UTC
> I'm running the latest install of KDE Neon (27/10/16), after upgrading from Kubuntu 16.10 (so KDE 5.7.5, I believe) which did not exhibit this issue.

Please not that this is an unsupported upgrade path! It might be that something broke badly.

> I _guess_ it's possible that virtualbox, teamviewer, and remmina all somehow 'broke' at the same time

You can easily test this. Use:
xdotool key XF86LogGrabInfo

That will print a section into /var/log/Xorg.0.log which will print which window currently holds the grab.

> If you're saying that this new behavior is 'by design', then I guess KDE is not designed for sysadmins who need to support other OSs remotely

If the opening of the menu on meta key is a problem to you, you can easily disable it for the time being. The other shortcuts should not fire when keyboard is grabbed. There is no change related to that at all. The global shortcut handling on X11 hasn't been changed for 12 months.
Comment 9 Martin Flöser 2016-11-04 09:05:11 UTC
did you verify which application has a grab? That's rather important for knowing where to look for the issue
Comment 10 atmarx 2016-11-04 16:45:55 UTC
Thanks for being understanding.  My apologies for sounding like an entitled jerk.

It is a fresh install of KDE Neon -- I meant upgrade in the sense that I went from 5.7.5 in Kubuntu to 5.8.2 (now .3).  I ended up reinstalling again since the other Neon install was only a few days old, and I must have messed something up with the shortcuts in the original install.  Remmina and Virtualbox work mostly as you say, passing the combos through.  Virtualbox though sometimes misses alt+f4 and prompts to close the VM instead of letting the VM handle alt+f4.

TeamViewer is a mess, not capturing any alt or meta key combos.  I've raised a bug with their devs, who are calling it a 'feature request' (when it provides a checkbox to capture and send key combos to the remote host and doesn't do that, I call it a bug, but whatever...)

With respect to the key grabs, kglobalaccel5 has almost all of them -- I'm guessing each one is a specific combo and correlates to the global shortcuts?
kwin_x11 has another handful. I'm not sure if the focus has to be in Teamviewer or VB, but with both of them up and running (a VM loaded in VB and a remote connection in TV), the logs aren't reporting any grabs for them.

If the grabs only register when the focus is on the apps, should I set a cron job to run it and then leave the app focused?
Comment 11 Martin Flöser 2016-11-04 18:38:49 UTC
To explain a little bit:

on X11 it's possible for a window to grab the keyboard. If a window does that all key events are sent to that window and not to others. So if e.g. Virtual Box has grabbed the key events, the global shortcut (like Alt+Tab) cannot be activated as kglobalacceld5 does not get the events.

If the global shortcut activates, it means the window has not grabbed the shortcut. And that's something you can verify with the grab tool.

Overall it sounds more like you have problems with those applications than with our software.
Comment 12 Peter Wu 2016-11-08 23:34:30 UTC
The same grab issue can be observed with QEMU.

Steps to reproduce:
1. Start qemu-system-x86_64 (no options needed, this will open the GTK GUI).
2. Click in the window, this will let QEMU grab the focus and change the title to
   "QEMU - Press Ctrl+Alt+G to release grab"
3. Press "Meta"

Actual results:
The Plasma kickoff menu opens.

Expected results:
The Plasma kickoff menu should not open.

I do not think it is useful to treat Meta specially to trigger an action given that all other shortcuts are disabled. Principle of least surprise is violated here.

For Ctrl-Alt-F1, Ctrl-Alt-Delete, etc., remoting software acknowledge that these complex shortcuts are interpreted by the host and QEMU/gvncviewer for example adds a menu option to send this keystroke. But the "Meta" key is not such a special key.

See also bug 371560 which requests the option to disable the "Meta" shortcut for Kickoff. (From a user's perspective, I also ran into the grab issue (this bug) and the linked Kickoff issue. Also, in all cases where Kickoff opened, I pressed Meta with the intent to press another key to trigger a shortcut, but then stopped. This got so annoying that I finally started looking for bug reports.)
Comment 13 Martin Flöser 2016-11-09 07:37:15 UTC
@Thomas: I need an evaluation from usability perspective. Is it expected that the menu does not open on meta press if an application grabbed keyboard? Or should we consider the modifier only shortcut as bypassing everything.

From a technical perspective I might not be able to block the meta shortcut on X11, which would mean rollback to not providing the feature in case the conclusion is that grabs should prevent opening it.
Comment 14 Thomas Pfeiffer 2016-11-10 23:59:55 UTC
If technically possible, modifier-only shortcuts should not bypass keyboard grabbing.
I would not consider them as equal to the likes of Ctrl-Alt-Fx. Those are "one level above" the desktop as they cen be used to switch away from it, whereas Meta for opening the start menu is a desktop feature.
Also, from a purely practical perspective, we don't want for example gamers to have to physically remove their meta key because they press it by accident all the time while playing shooters.

If it is not possible to prevent the meta key from triggering the menu opening even when an application grabs the keyboard on X11, however, I would not roll back the whole feature, under the assumption that removing the feature will have an impact on more people than not blocking it when the keyboard is grabbed.
As long as it is possible for users to manually disable it, that should be okay.
Comment 15 Martin Flöser 2016-11-11 06:43:27 UTC
On X11 I don't see a possibility. The complete feature is built up on bypassing keyboard grabs. AFAIK we cannot get a notification if another window grabs the keyboard.

On Wayland we will have more control, though there is no support for applications grabbing the keyboard at all.
Comment 16 Darin Miller 2016-12-06 06:15:38 UTC
Adding a note from a remmina perspective:

Meta keys are used frequently when remoting into a Windows box:
<meta> by itself on windows provides same functionality as Kicker (user text search for applications and files)
<meta>+D minimizes all windows
<meta>+e file manager (Explorer)
<meta>+<arrow> splits window half screen in corresponding arrow direction.
<mete>+<pause/break> windows settings
etc.

Options:
1. Disable kicker meta shortcut entirely
2. Disable meta key with script when launching key capturing applications, re-enable when application is closed.  This is a pseudo solution, as kicker would not work while app is running.  I switch to local desktop frequently when remoted to a windows box. Though I use krunner to launch most of apps, I would have used the meta key long ago if it worked.  Thus, new users will expect it to work if switching from windows.
3. Provide a list of apps in a config file or possibly a "window rules" setting that will disable the kicker meta key when they have focus.  However, this requires the user to maintain the key grab setting in the app and in the config file.
4. Honor the key capture state of the application that has focus. Can the key capture state of an app be determined when the app obtains focus? If so, auto disable meta-kicker relationship when respective apps are set to capture the keyboard and re-enable when non-key capturing apps or local desktop has focus.


Option 4 is preferred as it requires the least amount of configuration.  Options 1, 2 and 3 keep KDE in the tinkerer's realm and discourages users who do not like to fiddle with their system.
Comment 17 Martin Flöser 2016-12-06 18:04:13 UTC
Option 4 is not possible. We don't have any hints about that an application/window grabbed the keyboard.

Options 1-3 are all possible. For option 3 we do have a window rule which blocks global shortcuts and that also blocks the windows key triggering. We can also ship such rules by default, so that the user does not have to maintain them. But we will not be able to ship them to 5.8 users, that would have to go into Plasma 5.9.
Comment 18 Sacha C 2016-12-09 15:11:30 UTC
I've run in to the same issue.
Option 3 seems most reasonable to me since option 4 cannot be done. Hopefully it won't be a lot of work to maintain that list.

Out of curiosity, does anyone know how Gnome (or maybe it's GTK) handles it? I just tried with both VirtualBox and VMWare, and it seems to be able to suppress the meta key on the host and send it only to the guest.
Comment 19 Alexander Stehlik 2017-06-01 16:38:24 UTC
Hi there,

I can confirm this issue. When I use Synergy or Remmina and press the Meta key, the action is executed both on the KDE local host and the remote host.

For example: Synergy is active and mouse is moved to a Windows host. Then press meta key. The KDE menu AND the windows menu open at the same time.

This does not happen when I diable the modifier only shortcut in ~/.config/kwinrc by adding 

[ModifierOnlyShortcuts]
Meta=

and then using ksuperkey. This gives me back the correct behavior.

Hope this helps :)
Comment 20 Martin Flöser 2017-10-24 18:47:28 UTC
On Wayland there is now a protocol for shortcut inhibitions. I plan to implement this for 5.12. This would improve the situation on Wayland.

For X11 I can only recommend to use the block global shortcut window rule.
Comment 21 Kurt Kremitzki 2019-07-02 20:26:54 UTC
This issue is one of the only major usability problems I have with KDE, so I thought I might chime in. I see this issue when using virt-manager, the libvirt GUI tool, and synergy, a software keyboard & mouse switch.

In virt-manager, if I create, run, and log into a KDE VM, my keypresses get captured by the VM as expected. However, if I hit Meta, the Application Launcher opens on both the host machine and the VM. If I hit Alt+F1, only the Application Launcher in the VM opens, as expected.

The same thing happens in Synergy. If I am running a Synergy server on one KDE machine, and then run a Synergy client on another KDE machine, I can set it up so that moving my mouse to the side of one screen makes the cursor show up on the other machine's desktop, at which point my mouse and keyboard control gets passed to the Synergy client as expected. However, hitting Meta opens the Application Launcher on both the host and client, unexpectedly. Hitting Alt+F1 behaves correctly.
Comment 22 Marcus Hallett 2019-09-26 03:23:32 UTC
(In reply to Martin Flöser from comment #20)
> On Wayland there is now a protocol for shortcut inhibitions. I plan to
> implement this for 5.12. This would improve the situation on Wayland.
> 
> For X11 I can only recommend to use the block global shortcut window rule.

This is still a problem as of Plasma 5.16.x. The Wayland protocol implementation would be fabulous. It is implemented in GNOME's Mutter.
Comment 23 Roman Gilg 2019-12-11 12:19:38 UTC
How difficult is implementing this would you say? Maybe it could be a Google Summer of Code project.
Comment 24 David Redondo 2021-05-19 13:06:34 UTC
support for keyboard_shortcuts_inhibit has been added in the meantime