Bug 489113

Can confirm this also occurs on X11 when the keyboard is grabbed by an application such as a virtual machine viewer (virt-viewer and Looking Glass). It seems to affect any component or application that would normally have exclusive input grab.

OBSERVED RESULT
With virt-viewer or similar focused: 
Both the guest and host register Meta and the viewer loses focus. 

EXPECTED RESULT: 
Press Meta, only the guest should register the input and the host should not.

ADDITIONAL INFORMATION:
My workaround has been to apply a Kwin Window Rule to "Ignore Global Shortcuts" for these applications (Looking Glass in particular), but this is less than ideal. 
Is there a way to determine if the input is currently being monitored/grabbed and act accordingly? Let me know if I can provide any kind of info/logs with Xprop or similar debugging.

I'm surprised there aren't more reports on this, this is a heavy hitter for usability. I work and play in virtual machines and VNC sessions very often, isolated keyboard input is critical. I'm also finding bit by bit that components of the Plasma desktop like Klipper do not honor the "Ignore Global Shortcuts" window rule that I had been using as a crutch. Of course that is not the solution anyway.

Looking through old history, it looks like keyboard inhibiting wasn't working in X11 until 2020 in the first place, and this commit implemented it at the time: https://invent.kde.org/plasma/kwin/-/merge_requests/23
Could this same inhibitor function (isKeyboardShortcutsInhibited) be ported to the new Global Shortcuts system?

Correction to last post, had too many tabs open. 
https://invent.kde.org/plasma/kwin/-/merge_requests/23 addresses how Wayland at the time added support, not X11.

Can confirm this also occurs on X11/Opensuse Tumbleweed  when the keyboard is grabbed by an application such as a virtual machine manager with an open virtual machine running.

OBSERVED RESULT
With virt-viewer or similar focused: 
Both the guest and host register Meta and the viewer loses focus. 

EXPECTED RESULT: 
Press Meta, only the guest should register the input and the host should not.

ADDITIONAL INFORMATION:
My workaround has been to use virt-viewer in kiosk mode but ultimately I reverted to Plasma 6.0.5

Can confirm this happens for virtual box and Inputleap as well  
Inputleap bug: https://github.com/input-leap/input-leap/issues/1925

Hello, are there any progress or ideas? I am also sticking to Plasma 6.0.5 primarily due to this bug. 

The issue was not resolved by simply reverting commit 219499707e1f85d318bb23ce305de4f3cb0e0eb3 as speculated, nor the immediate parents in kglobalacceld. This is part of the bigger change to global shortcuts at https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44 and is also connected to three other Plasma components, noted in the MR. 
Perhaps the issue lies in one of those components and not kglobalacceld?

So the problem is that on x11, we changed to using xcb record to trigger all shortcuts. This was needed to support modifier-only shortcuts, which need to be triggered on release, but key grabbing does not report any key release events. 

As per the x record extension documentation [0], " Core X device events and X extension device events with a code value between first and last inclusive that are not delivered to any clients will be recorded." This seems to imply that events delivered to clients will not be recorded. However, the actual behavior in this bug report is that events grabbed by other clients are still recorded. I don't know if I am mis-interpretting the documentation, or if this is an upstream bug.

Alternately, I think we might have to remove modifier-only shortcut functionality on x11.

[0] https://www.x.org/releases/X11R7.6/doc/libXtst/recordlib.html#protocol_ranges

Thanks for the details, this portion of Plasma is all new to me. Kind of interesting that the first result I read for "xcb record" recommends against using it: https://stackoverflow.com/a/20825635. There's no way to catch and address this particular state with the existing solution? 

Personally I don't use modifier-only shortcuts, and it was my understanding that X11 in Plasma was frozen a good while ago, so I would not miss the feature if the change were reverted to restore input capture.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/57

(In reply to Blazer Silving from comment #8)
> Thanks for the details, this portion of Plasma is all new to me. Kind of
> interesting that the first result I read for "xcb record" recommends against
> using it: https://stackoverflow.com/a/20825635. There's no way to catch and
> address this particular state with the existing solution? 

Unfortunately we need the key release events to handle modifier-only shortcuts. Please let me know if there is a better way of doing it....

> Personally I don't use modifier-only shortcuts, and it was my understanding
> that X11 in Plasma was frozen a good while ago, so I would not miss the
> feature if the change were reverted to restore input capture.
Previously kwin had experimental support for modifier only shortcuts. In 6.1 we added the functionality to kglobalacceld, where it better belongs, and additionally added support for multi-modifier modifier-only shortcuts. Afterwards, we removed the modifier only shortcuts code from kwin. So just reverting the kglobalacceld change will leave us in an awkward situation where the old support from kwin is also gone..

Git commit d6160f565087979cd07db005536777f3f76b4da6 by Yifan Zhu.
Committed on 02/08/2024 at 23:56.
Pushed by fanzhuyifan into branch 'master'.

plugins/xcb: only handle modifier presses in XRecord

219499707e1f85d318bb23ce305de4f3cb0e0eb3 moved handling of all events to
XRecord, which caused global shortcuts to trigger even when input is
grabbed. Partially revert the change to handle normal key presses in
nativeEventFilter. To preserve correct handling of modifier-only
shortcuts, handle modifier presses in XRecord, and clears the
modifier-only state for other presses.

M  +4    -0    src/globalshortcutsregistry.h
M  +5    -0    src/kglobalaccel_interface.cpp
M  +6    -0    src/kglobalaccel_interface.h
M  +23   -2    src/plugins/xcb/kglobalaccel_x11.cpp

https://invent.kde.org/plasma/kglobalacceld/-/commit/d6160f565087979cd07db005536777f3f76b4da6

Hello, i've built and tested the latest kdesrc-build pull of kglobalaccel, but the issue persists. 
Same behavior on default config, just a quick Meta/Super tap in a fresh profile is enough to test. Verified d6160f565087979cd07db005536777f3f76b4da6 is included, but I will try on the latest live ISO when it auto-builds to be sure. 

Another test I use is Super+Q to launch Rofi as Plasma shortcut, with Powertoys Run in a Windows guest on the same mapping, so it's not just single-modifier shortcuts affected. Unfortunately this is the edge of my experience, i'm not much more help aside from troubleshooting and tweaking/debug. 

Is a hard revert even possible, given the dependency on kguiaddons, kwin, kwindowsystem? Their linked changes in the MR actually seem very small, earlier commits and other components are likely involved as well. Given X11 is already hanging on by a thread and close to being unsupported, this is a really crappy situation.

(In reply to Blazer Silving from comment #12)
> Hello, i've built and tested the latest kdesrc-build pull of kglobalaccel,
> but the issue persists. 
> Same behavior on default config, just a quick Meta/Super tap in a fresh
> profile is enough to test. Verified d6160f565087979cd07db005536777f3f76b4da6
> is included, but I will try on the latest live ISO when it auto-builds to be
> sure. 

Unfortunately the commit only fixes the issue for ordinary shortcuts (not modifier-only). For modifier-only shortcuts, we don't want to grab those, since that might interfere with other applications, and we need to trigger on release.

> Another test I use is Super+Q to launch Rofi as Plasma shortcut, with
> Powertoys Run in a Windows guest on the same mapping, so it's not just
> single-modifier shortcuts affected. Unfortunately this is the edge of my
> experience, i'm not much more help aside from troubleshooting and
> tweaking/debug. 

However, the commit should fully restore the previous behavior to that in 6.0 for other shortcuts. E.g., I tested in system settings key assignment, and assigning an existing shortcut doesn't trigger the shortcut. For this particular issue you are mentioning, do you know if it is a regression from 6.0? (One way to test may be using an ISO with plasma 6.0) Maybe the virtual machine viewer is not correctly grabbing Super+Q and preventing events from propagating?

(In reply to Blazer Silving from comment #12)
> Hello, i've built and tested the latest kdesrc-build pull of kglobalaccel,
> but the issue persists. 

Also, just to make sure, you would need to compile kglobalacceld, instead of kglobalaccel.

> For this particular issue you are mentioning, do you know if it is a regression from 6.0? 
> Maybe the virtual machine viewer is not correctly grabbing Super+Q and preventing events from propagating?

Yes, very much a regression, these applications have worked for years in X11, and downgrading my main desktop's system packages from 6.1 to 6.0.5 remediates the issue. Running 6.1 in kdesrc-build environment can reproduce the issue predictably, and my laptop is also running 6.1 system-wide and can reproduce using Barrier (Input Leap). 

As mentioned earlier, the "Ignore Global Shortcuts" Kwin rule only works halfway, it is not honored by third party applications, or even all Plasma applications (Ctrl + ` opens Klipper over the viewer window while the VM underneath also opens the clipboard manager). 

> Also, just to make sure, you would need to compile kglobalacceld, instead of kglobalaccel.
For sure, I use the `kdesrc-build workspace` target so it builds all. The commit is visible in src/kglobalacceld git log. I also ensured the running process was `/home/kdesrc-build/kde/usr/lib/libexec/kglobalacceld`, using the custom login session calling `libexec/startplasma-dev.sh -x11` from SDDM.

How should I reproduce the issue? Also could you verify that assigning existing shortcut in system settings no longer triggers the shortcut?

(In reply to Blazer Silving from comment #6)
> Hello, are there any progress or ideas? I am also sticking to Plasma 6.0.5
> primarily due to this bug. 
> 
> The issue was not resolved by simply reverting commit
> 219499707e1f85d318bb23ce305de4f3cb0e0eb3 as speculated, nor the immediate
> parents in kglobalacceld. This is part of the bigger change to global
> shortcuts at https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44
> and is also connected to three other Plasma components, noted in the MR. 
> Perhaps the issue lies in one of those components and not kglobalacceld?

So the kwin MRs are only about removing modifier-only shortcut functionality from kwin, and sending pointer events to kglobalacceld. The other MRs are about enabling assigning modifier-only shortcuts. Only the kglobalacceld MR should be relevant to the bug you are discussing.

Given that the bug persists after reverting all the relevant kglobalacceld commits, this suggests that the issue you are raising might be different from the one originally reported here. So I would suggest opening a new bug report and moving the relevant discussion there.

Good news, a clean build of kglobalacceld now reflects the change, something must have been cached. 

Multi-key shortcuts are indeed fixed. Using Barrier as a host in the build with your patch, Meta+Q only triggers within the target screen. This also works for special keys like Fn+F2 (volume up/down), and this also fixes Looking Glass and virt-viewer. My laptop with 6.1.3 release can connect the opposite direction with Barrier and replicate the broken behavior, Meta+Q triggers on both screens. 

Meta by itself (modifier-only) still triggers in all cases, but I just confirmed Kwin in 6.0.5 also had the same behavior in a fresh profile with whichever method Kwin used, so there's no regression any longer with this fix. Sorry for the mis-report and thanks!

(In reply to Blazer Silving from comment #18)
> Good news, a clean build of kglobalacceld now reflects the change, something
> must have been cached. 
> 
> Multi-key shortcuts are indeed fixed. Using Barrier as a host in the build
> with your patch, Meta+Q only triggers within the target screen. This also
> works for special keys like Fn+F2 (volume up/down), and this also fixes
> Looking Glass and virt-viewer. My laptop with 6.1.3 release can connect the
> opposite direction with Barrier and replicate the broken behavior, Meta+Q
> triggers on both screens. 
> 
> Meta by itself (modifier-only) still triggers in all cases, but I just
> confirmed Kwin in 6.0.5 also had the same behavior in a fresh profile with
> whichever method Kwin used, so there's no regression any longer with this
> fix. Sorry for the mis-report and thanks!

Glad to here things are working!