https://bugs.kde.org/show_bug.cgi?id=486034
--- Comment #2 from Bruno Filipe <bmil...@gmail.com> --- (In reply to Zamundaaa from comment #1) > Can confirm. KWin is lacking the key press deduplication logic that's > required for multiple devices on the same seat to cooperate with each other. Hey Zamundaaa, thanks for the quick confirmation. I got a bit of practical evidence on what's happening after playing a bit with libinput debug (sudo libinput debug-events --verbose) , along with clicklockd and also a script using python-evsieve to simulate my scenario. In summary, like you already said, the current issue in kwin Wayland behavior is that when the same key is pressed/released on multiple seats it lacks any logic to avoid repeating events to mess with each other. In my scenario what happens is this: -event4 POINTER_BUTTON +1.541s BTN_LEFT (272) pressed, seat count: 1 # Real mouse BTN_LEFT pressed, from neutral state - Self-explanatory -event15 POINTER_BUTTON +1.541s BTN_LEFT (272) pressed, seat count: 2 # Virtual mouse BTN_LEFT pressed - This click should be ignored since we're already in pressed state on another seat (real mouse), but it is not. It generates a double-click instead. -event4 POINTER_BUTTON +3.125s BTN_LEFT (272) released, seat count: 1 # Real mouse BTN_LEFT released - This one should also be ignored since virtual is still in pressed state, but it is not. event4 POINTER_BUTTON +4.589s BTN_LEFT (272) pressed, seat count: 2 # Real mouse BTN_LEFT pressed again - Also should be ignored since virtual is still in pressed state, but it is not. event4 POINTER_BUTTON +4.677s BTN_LEFT (272) released, seat count: 1 # Real mouse BTN_LEFT released - Also should be ignored since virtual is still in pressed state, but it is not. -event15 POINTER_BUTTON +4.677s BTN_LEFT (272) released, seat count: 0 # Virtual BTN_LEFT released - Now kwin/Plasma should actually release effectively. A bit difficult to explain, but something like this. -- You are receiving this mail because: You are watching all bug changes.
