Bug 484525

Summary:	Global Shortcuts Portal: Binding activated / Binding released events are triggering inconsistently
Product:	[Plasma] xdg-desktop-portal-kde	Reporter:	winblocker
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	aleixpol, jgrulich, kde, kdedev, nate
Priority:	NOR
Version First Reported In:	git-master
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description winblocker 2024-03-26 13:39:51 UTC

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
If you hold down a binding set up through the portal a constant stream of "Binding activated" events are being send. This is fine. But this stream stops when an additional key is pressed even though the keys required for the binding are still being held. And what is even worse is that if i release the key that is not assigned to the binding a "Binding deactivated" event is being send.
This breaks all push to talk use especially when playing video games. It will cancel your push to talk every time you move with wasd for example.

STEPS TO REPRODUCE
1. Bind some portal bindings
2. Watch the events as you press the binding + additional buttons

OBSERVED RESULT
"3rd party" keys break portal bindings

EXPECTED RESULT
"Binding activated" should fire as long as all key that are assigned to the binding are being held. Regardless of other keys. "Binding deactivated" should only trigger if one of the keys that are assigned to the binding are released.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6900 XT

ADDITIONAL INFORMATION
Python app for your testing convenience:
https://gist.github.com/Aviana/a3a0368172e326d6ccc57cb254c1e569

Comment 1 Aleix Pol 2024-03-28 19:00:38 UTC

Can you please provide an implementation that we can test? It would make our life considerably easier.

Comment 2 winblocker 2024-03-28 19:16:30 UTC

See "ADDITIONAL INFORMATION" at the end of the original post.

Comment 3 winblocker 2025-03-01 10:53:16 UTC

Can i get an official response to this? I just re-tested it myself and it is still a problem for me. Is this intended behavior? It has become more relevant recently as Electron has committed to the portal and several apps which utilize push to talk functionality build on top of it.

I just re-tested this and it is still showing this problem. A way of testing was already provided in the original post.

Operating System: Arch Linux 
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2

Comment 4 David Redondo 2025-03-04 07:34:30 UTC

Isn't it somewhat expected? If I have two shortcuts 
ctrl + a 
ctrl + alt +a

if I hold ctrl+a and then press alt another binding is activated.

Comment 5 winblocker 2025-03-05 01:07:26 UTC

(In reply to David Redondo from comment #4)
> Isn't it somewhat expected? If I have two shortcuts 
> ctrl + a 
> ctrl + alt +a
> 
> if I hold ctrl+a and then press alt another binding is activated.

No what i am expecting is that while i am holding down keys on the keyboard all registered bindings that match a subset of those keys are triggered. This is the behavior of X.org and windows due to apps listening for all inputs there. I have already mentioned in the initial post a push to talk scenario where the current behavior is a problem.
But once again here is the scenario:
You have a voice communication software the requires you to hold a key combination to activate the microphone (push to talk). While you are holding the combination you decide to for example move your character in a video game. So you press the W key for example. If you do that your microphone deactivates and thus interrupting your speech.

Comment 6 winblocker 2025-03-05 01:51:13 UTC

Having thought about this a bit more i would consider it a feature if multiple apps could register the same combination through the portal. It should be up to the user to avoid having multiple apps on the same combination. There could always be some sort of warning but there might be a use-case of triggering multiple apps with the same key combination.