| Summary: | Plasma does not filter repeated media key events from different devices on Wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | James R Larrowe <larrowe.semaj11> |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | duha.bugs, fanzhuyifan, larrowe.semaj11, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.1.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | video of pressing the mute key several times | ||
|
Description
James R Larrowe
2024-08-01 04:14:42 UTC
IMO shouldn't it be the responsibility of the driver to make sure that we don't get two events from two different devices? (In reply to fanzhuyifan from comment #1) > IMO shouldn't it be the responsibility of the driver to make sure that we > don't get two events from two different devices? In the Launchpad bug I mentioned the person who wrote that part of the driver recommended it be put in userspace. I think part of the issue is that devices send the event from the keyboard, from the WMI device, or both. Ok on git master (wayland) I cannot reproduce by simulating the situation by simultaneously using two keyboards with the mute key. So I plugged in two keyboards, and press both mute keys simultaneously multiple times. I ran `sudo libinput debug-events --show-keycodes` and got the following events: ``` -event7 KEYBOARD_KEY +4.568s KEY_MUTE (113) pressed -event5 KEYBOARD_KEY +4.570s KEY_MUTE (113) pressed -event7 KEYBOARD_KEY +4.646s KEY_MUTE (113) released -event5 KEYBOARD_KEY +4.699s KEY_MUTE (113) released event5 KEYBOARD_KEY +5.875s KEY_MUTE (113) pressed -event7 KEYBOARD_KEY +5.886s KEY_MUTE (113) pressed event7 KEYBOARD_KEY +5.955s KEY_MUTE (113) released -event5 KEYBOARD_KEY +6.003s KEY_MUTE (113) released event5 KEYBOARD_KEY +7.404s KEY_MUTE (113) pressed -event7 KEYBOARD_KEY +7.427s KEY_MUTE (113) pressed event7 KEYBOARD_KEY +7.496s KEY_MUTE (113) released -event5 KEYBOARD_KEY +7.515s KEY_MUTE (113) released ``` Note that this should be equivalent to the sequence of events generated in the original report. However, each press still correctly mutes/unmutes the audio -- it is as if only a single press is emitted. In particular, if I open kwin debug console (search for that in krunner) and go to events, I only see a single pair of press and release events there. There are two possibilities: 1. Simulating the issue with two different keyboards this way is actually different from the issue. 2. For some reason the issue is fixed in git master. Given that I *can* reproduce on plasma 6.1 wayland, let's call this fixed in plasma 6.2. There has been some changes to input handling, but I am not sure which commit exactly solved the issue. Feel free to reopen if the issue persists for you on plasma 6.2, or current git master. I'm already on kde-unstable, do you know if there is an easy way to use 6.2 on Arch without building it all myself? Upgrading one package would be great but I'm okay with a few, as long as it's not the whole desktop environment. Looking into AUR helpers in the meantime, since it would be unreasonable to manage all of that myself. (In reply to James R Larrowe from comment #5) > I'm already on kde-unstable, do you know if there is an easy way to use 6.2 > on Arch without building it all myself? Upgrading one package would be great > but I'm okay with a few, as long as it's not the whole desktop environment. > > Looking into AUR helpers in the meantime, since it would be unreasonable to > manage all of that myself. Plasma 6.2 hasn't been released yet, so it is not in kde-unstable. Garuda used to maintain a repo containing git builds of everything. I am not sure if it is still maintained (https://forum.garudalinux.org/t/kde-6-repository-testing/31442/26) If you just want to test things out you should try a neon unstable live usb disk. That is the least disruptive way to see if things are fixed for you in the upcoming 6.2 release. I run the full git session via kdesrc-build (https://community.kde.org/Get_Involved/development). But that's a ton of stuff to compile. If you just want to upgrade a few packages, my hunch is that kwin might be the package containing the fix. So you might want to try just compiling the git version of that. |