Bug 465463

Sounds like our filter somehow mixes up extra button 2 and 3. Could  you paste  the 
'[ButtonRebinds][Mouse]' section of ~/.config/kcminputrc just to be sure that it writes the correct config for button 2 and 3?

(In reply to David Redondo from comment #1)
> Sounds like our filter somehow mixes up extra button 2 and 3. Could  you
> paste  the 
> '[ButtonRebinds][Mouse]' section of ~/.config/kcminputrc just to be sure
> that it writes the correct config for button 2 and 3?

Sure:
[ButtonRebinds][Mouse]
ExtraButton1=Key,A
ExtraButton2=Key,B
ExtraButton3=Key,C
ExtraButton4=Key,D
ExtraButton5=Key,E

(I reassigned them to A-E before doing this, as this makes it easier to test follow the effects)
So the KCM is doing the right thing. But it's not just Button 3, the whole thing is messed up.
Here is what happens when I use wev with this setup:
Button 1: a
Button 2: b
Button 3: b
Button 4: b
Button 5: c

(Button 4 and 5 correspond to the left/right action on the scrolling wheel. I can map those to regular buttons instead of horizontal scrolling using ratbagd or solaar.)

So something is wrong with the way it increments, maybe?
There is also a button 13, which is not really a button, but the (mechanical) switch that activates/deactivates clickless scrolling.
I can set that, too and it will correctly output the key that I set for this button. So maybe just the increment isn't the answer either?

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

Git commit cc4d99aea4948c10c159328ff15f6783ae974eeb by Vlad Zahorodnii, on behalf of David Redondo.
Committed on 10/02/2023 at 09:27.
Pushed by davidre into branch 'master'.

Fix button to Qt::MouseButton mapping

Even though the names seem to match, QtWayland maps button values
to enum values in ascendung order (as it does on X11). The wrong
mapping is usually not a problem because we send the native button
events to clients. However when the Qt names or values are used
for communication between KWin and a client this leads to
misunderstandings.
FIXED-IN:5.27.1

M  +4    -4    autotests/libinput/mock_libinput.cpp
M  +3    -5    src/mousebuttons.cpp

https://invent.kde.org/plasma/kwin/commit/cc4d99aea4948c10c159328ff15f6783ae974eeb

Git commit e0b289a6f1a665c77b1112049b3c70536770f27f by David Redondo.
Committed on 10/02/2023 at 09:42.
Pushed by davidre into branch 'cherry-pick-cc4d99ae'.

Fix button to Qt::MouseButton mapping

Even though the names seem to match, QtWayland maps button values
to enum values in ascendung order (as it does on X11). The wrong
mapping is usually not a problem because we send the native button
events to clients. However when the Qt names or values are used
for communication between KWin and a client this leads to
misunderstandings.
FIXED-IN:5.27.1


(cherry picked from commit cc4d99aea4948c10c159328ff15f6783ae974eeb)

M  +4    -4    autotests/libinput/mock_libinput.cpp
M  +3    -5    src/mousebuttons.cpp

https://invent.kde.org/plasma/kwin/commit/e0b289a6f1a665c77b1112049b3c70536770f27f

Thanks for looking into this. I can confirm that the change fixes the issue.

Thank you, for the the very detailed report!

(In reply to David Redondo from comment #7)
> Thank you, for the the very detailed report!

Well, directly after the whole kwin restarting issue, the ability to rebind mouse buttons was the major holdback for me personally regarding the switch to Wayland.
My muscle memory is just way too trained using these after +10 years of using imwheel. So the motivation to dig deep to analyze this was quite high for me. :)