No way to configure mouse button number

(*** This bug was imported into bugs.kde.org ***)

Package: kcminput
Version: 2.0 (using KDE 2.2.1 )
Severity: wishlist
Installed from: compiled sources
Compiler: gcc version 2.95.2 20000220 (Debian GNU/Linux)
OS: Linux (i686) release 2.4.3
OS/Compiler notes:

currently there is only support for 3 mouse buttons and the mouse-wheel. But many mice have more than 3 mouse buttons (e.g. ms intellimouse explorer) so it would be appropriate to let the user configure the additional buttons to do some window operations or to emulate keyboard shortcuts.

I hadn't found a possibility to do this using the x-toolkit. There is only support for maximum 5 buttons and these "buttons" are used by a 3 button mouse with mouse wheel.

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)

The intellimouse (explorer, optical, ...) mice have 5 buttons, with two being
on the side that default to being used for back/forward in IE, which many
people (myself included) become accustomed to. Mozilla and Phoenix support
this, it's the only thing preventing me from using Konq most of the time. :)

*** This bug has been marked as a duplicate of 48062 ***

This is different than bug# 48062, since 48062 has to do with "modifier" buttons (whatever
those are supposed to be...), and this is just about recognizing a button as a normal key.

I'm wondering that this wish is very old (over three years?) and the status is still "new".

Really it would be a great help if it would be possible to define how many buttons and or wheel a mouse has. And assigning some features to this buttons.

I tried around with the mapkey-pointer feature of X but with no/less success. Assigning a "doubleclick"-event to a pointer seems to be impossible.

Using new Logitech MX1000 Laser with 10 buttons :-) Yes, even the mouse wheel can be pressed down, left and right :-)

*** Bug 71328 has been marked as a duplicate of this bug. ***

Just bought an MX1000 some weeks ago. Indeed, the only way to make the extra buttons (including thumb buttons!) work is to use imwheel (or equivalent software) and remap them to some keyboard events.

That's nice, working great and full of possibilities, but far from easy for new users. They would expect those buttons to work out of the box, IMHO.

This seems to be a Qt limitation, and if the documentation is up to date on this subject, it still is in Qt 4 : http://doc.trolltech.com/4.0/qt.html#MouseButton-enum (I haven't looked at the source).

Perhaps you, KDE folks, will be able to push TrollTech in the right direction ?

I am in the same boat concerning my new mx1000. It would be great to be able to configure this without needing to use a 3rd party app to configure the extra buttons.

I would suggest putting configuration in the kcm mouse module, however--users will not expect mouse configuration to be in a keyboard/keymap list. :)

If it does turn out to be a limitation of qt, then it would be great to have a control module, or portion thereof, that will configure the imwheel (or other app) to remap the buttons. Until a solution is found, I guess I'll configure imwheel by hand.

Thanks!

Zak.

*** Bug 72199 has been marked as a duplicate of this bug. ***

Sorry people, but this is a Qt issue and has to be resolved by Trolltech. If/when Qt supports this, we have to reassign back to kdelibs so that our libraries are adapted.

Or does Qt support it already?

Pasting an email from TrollTech here:

----------------
Qt can only provide an API to 5 mouse buttons, as other windowing
systems, i.e. Win32, do not support anything beyond L, R, M, X1 and X1
at this point.

http://doc.trolltech.com/4.0/qt.html#MouseButton-enum

KDE, and specifically KDE's window manager, could implement handling for
more mouse buttons by reimplementing QWidget::x11Event() in a platform
specific fashion.
----------------

TrollTech has already provided an example method for getting this to work, as shown above.

I do know that many other window managers have supported > 5 mouse buttons for years.. most of those since 4.0 of X11R6 first came out. I don't know if putting pressure on TrollTech would help, I don't really buy their reason (Win32 limitations) as anything approaching valid.

However, KDE users have been waiting for > 5 mouse button support for many a year. Is waiting for Trolltech to get off their collective asses the best of ideas? They've clearly stated that Win32 is their target, not Linux (with their comment above).

So.... we should wait until a new version of Windows comes out, hoping it supports more than 5 events, then wait as the years pass, hoping that TrollTech will play catchup to that???

I don't really see KDE lagging behind by 10 years in the mouse usability arena, as a logical target for the KDE community. Am I missing something here?

Reassigning back to kdelibs.

What is the status of this bug?

Not sure what you mean by requesting the status. It's still unresolved, if that's what you mean...

*** Bug 94082 has been marked as a duplicate of this bug. ***

Hi Mom,

Christopher's crew was finishing up when I took the kids to the Dojo
this morning. It looked a lot better so I gave him the check. He said
to call him back if there is anything else they forgot.

Have a great day. Love you,
Don

<email address hidden> wrote:

[bugs.kde.org quoted mail]

Is there any date, when this bug will be fixed?

I think this would be nice to have as well.

This would be very nice, but after two months of scrolling my screen whenever I press the "paste" button, I'd just be happy if I could get xev to see button 8 so I could remap it to button 2. This whole blasted mouse thing is a twisty maze of out of date and disconnected information.

I've also been missing this feature for years and was hoping it would show up in 4.x, especially with the various new switching effects which would be much more useful when mapped to mouse buttons. A useful workaround for now is xbindkeys, which can map at least some mouse buttons to custom keyboard shortcuts, but I really think KDE should allow us to configure mouse buttons just like any other keyboard shortcuts (after all, the keyboard configuration system is one of the great things about KDE).

Sorry to respond to an ancient bug, but this is an accesibility issue for some people. I have a very very limited example in that moving windows is rather inconvenient for me in kwin compared to how I move them in fluxbox, where I just have to say in my 'keys' file, how and where to handle any mouse buttons it finds. For example, I use:
OnWindow Mouse9 :StartMoving

Which lets me move windows around by clicking anywhere on them with mouse9 and moving around. Unless my titlebars are huge, it's physically frustrating to hit the titlebars (due to shakiness). I use 'stuck keys' to hold down alt while I move a window around if I have to, but I'm very happy being able to just use one button instead. (using something like btnx to map ALT and Mouse1 to Mouse9 just passes the ALT+Click through to the app right past the window manager)

This was probably a wasted effort, I just wanted to be one more voice of 'me too' in favor of more comprehensive mouse support. Thanks.

IMHO both mouse buttons 4 and 5 and also the "forward" and "backward" keys on some keyboards should be implemented out-of-the-box. A must in usability ;)

A necessary feature for a modern desktop.

I found this very same bug under the bug report numbers: 226370, 34362 and 227040.
It is quite poor, that this usability bug has been consistently there for almost a decade despite the fact that it has rank 26 regarding the votes of all bug reports. There seems to be a hint for a solution pointed out by Trolltech.
As stated above it is a nogo that KDE still remains the only platform on which extra mouse buttons do not work out of the box.

*** Bug 242645 has been marked as a duplicate of this bug. ***

Qt bug list suggests that this issue will be fixed in Qt 4.7.

http://bugreports.qt.nokia.com/browse/QTBUG-9214
http://bugreports.qt.nokia.com/browse/QTCREATORBUG-899

KDE just needs to implement support in Nautilus etc.

As far as I can see those patches are implementing only back and forward buttons (not all additional mouse buttons) and only for the Qt Creator help browser. Rekonq has support at least for the back button, so it is possible in KDE.

(In reply to comment #26)
> Qt bug list suggests that this issue will be fixed in Qt 4.7.
> http://bugreports.qt.nokia.com/browse/QTBUG-9214

<<snip>> Todd is correct in his reply: the qt updates implement only two additional buttons (and the requirement seems to have been inspired by Firefox on mobile devices). I have been thinking, QUITE HARD, about the origins of the problem.... and how to solve it pretty easily for the "special case" of X11. Here's my essay - it's actually quite short.

The authors of the qt-X11 mouse interface looked at the byte of mouse mapping buttons which X11 returns with a mouse event... and (apparently) chose to give the same bits to the user. A couple of bits are not used for button mapping, and so, obviously, there aren't enough bits returned in the bit-field to map all the buttons in a typical "gamer" mouse.

HOWEVER: X11 easily supports additional mouse buttons, and the events ("mouse press" and "mouse release") which it emits to listening software specify those higher=numbered buttons! You Linux-X11 people with "big" mice can check this out, it's easy to see. First, to see what X11 has heard about, open any kind of terminal window within your KDE Session (a "kterm" does just fine) and run /usr/bin/xmodmap with the "-pp" command line option. ("-pp" asks xmodmap to display the current button mapping on $STDOUT.) Here's the response which I get for my mouse:

rickst29@my3rdbox ~]$ xmodmap -pp
There are 13 pointer buttons defined.

    Physical Button
     Button Code
        1 1
        2 2
        3 3
        4 4
        5 5
        6 6
        7 7
        8 8
        9 9
       10 10
       11 11
       12 12
       13 13

[rickst29@my3rdbox ~]$

Yes, X11 understands that my mouse can emit events for 13 different numbered buttons. (NOT 3, or 5, or 7.) There is another program which you want to try out, so that you can *SEE* the X11 events: run "xev", move your mouse into the little test panel which the program creates, and start pressing/releasing *YOUR* buttons. You will find them all, and the printf() shows them by number. (Do take note... every bit of mouse motion creates another event, so you might want to pipe it into file, and edit the file afterward.)

You usually **DON'T** have to create them via "keyboard emulation" tricks. evdev tries to get the number of mouse buttons dynamically, from HAL. In good Distros, the only need for an explicit usually (And eventually, it will be udev instead -- but if the X11 programmers are doing all the heavy lifting for us, qt and KDE should take advantage of their work on this platform.)

Many of us know, already, that software built on GTK+ has no problems using these "extra" buttons. (I use compiz, instead of Plasma, to provide my compositing desktop within KDE -- just so that I can do neat things with all those buttons !!) The user doesn't have to configure weird keyboard emulation tricks, it just works.

So, where did qt go wrong? They inspected the API, rather than handling button event...

(In reply to comment #10)
> Pasting an email from TrollTech here:
>
> ----------------
> Qt can only provide an API to 5 mouse buttons, as other windowing
> systems, i.e. Win32, do not support anything beyond L, R, M, X1 and X1
> at this point.
>
> http://doc.trolltech.com/4.0/qt.html#MouseButton-enum
>
> KDE, and specifically KDE's window manager, could implement handling for
> more mouse buttons by reimplementing QWidget::x11Event() in a platform
> specific fashion.
> ----------------

Old post, but let me snuff that claim from the qt respondent. (It was false then, and remains false now.) This claim that Windows cannot support "gaming" mice is, and was, pretty absurd. These mice were invented for Windows games first, and they're extra buttons are now used in huge numbers of programs on that platform. The same can be said for programs, Window Managers, DE's, and ToolKits based on GTK+.

qt's enumeration doesn't support more buttons. (And neither does the X11 button state Byte; you need to follow the events and construct "wider" Table within "your own software". By which I mean qt software, of course ;)

It is strategically preferable to work this out inside of qt, rather than KDE. First problem: Writing this low-level support into KDE on X11 would lead to another implementation for KDE on Windows, gumming up KDE with platform-specific code (in a fundamental conflict with the isolation from platform hardware code which we want to maintain). Second problem: Lots of qt platforms which might not need an entire Linux-based Desktop (Televisions, Refrigerators, etc.) might still have need for multi-button, 2D pointer devices within a qt-based GUI. Can you say "Meego"? Sure you can, and I'll bet that Intel agrees me on this.

status update. After a helpful discussion with some late-night qt Devs on their IRC channel, I have just opened a bug with qt -- and I intend to provide a functional, ready-for-review update for this "ancient" issue. (Both the code and the Doc.) No comments yet, not even extra info posted by me-- just the basic definition of the issue. http://bugreports.qt.nokia.com/browse/QTBUG-16092

Within X11, the "button" field of the typedef for XButtonPressedEvent and XButtonReleasedEvent is an unsigned int. *NOT* a bitmask, and the X11 mask field is limited to 5 bits. So, if a higher-numbered button is ALREADY in pressed State when the mouse enters your App Window, there's no way to advise you of that. We'll only be able to show a single button number for a "high-numbered" press or release which takes place within YOUR window, with masked state of buttons L, R, M, X1 and X1 (only!) provided in the too-small button mask field.

Unsure whether I'll have to create a subclass to provide "extended" versions of the API. I'll SWAG that it will b necessary, for BC... there's just not enough bits left to play with. :((

*** Bug 272728 has been marked as a duplicate of this bug. ***

The patch for qtbug 16092 caused broken BC, but I've got another way.

And THAT project will not only give us all 32 possible buttons, it will also provide the full 32-bit ButtonStateMask ** whenever a user executes the 'READ' function **.

So, you could check for concurrently pressed buttons when a MouseButtonDblClick Event is received... and make the combination of both invoke certain code as a special "shortcut", different from either oif those buttons alone. You would also be able to check for pressed ButtonStateMask buttons after receiving WHEEL events-- creating new shortcuts, or actions, for those combinations as well. (How about scroll up/scroll down + RIGHTBUTTON == zoom out, zoom in? Entirely on the mouse, without reaching for the keyboard at all.

I can do it, at least on x11. Whther Qt wil accept it is another matter entirely.

sounds huge, good luck!

I'm happy to declare this bug RESOLVED by upstream changes, coming in Qt5. For reference, my Qt changeset was: http://codereview.qt-project.org/#change,8548,patchset=6 and the corresponding Qt BUGID was https://bugreports.qt.nokia.com//browse/QTBUG-22642.

Because Qt5 will include support for up to 31 buttons, KWin (and other KDE
programs) may use those buttons- if the user's platform and pointer device are
recognized as "Gamer-Button Equipped" by Qt itself.

Here is the new set of button names within qnamespace.h:

    enum MouseButton {
        NoButton = 0x00000000,
        LeftButton = 0x00000001,
        RightButton = 0x00000002,
        MidButton = 0x00000004, // ### Qt 5: remove me
        MiddleButton = MidButton,
        XButton1 = 0x00000008,
        BackButton = XButton1,
        ExtraButton1 = XButton1,
        XButton2 = 0x00000010,
        ForwardButton = XButton2,
        ExtraButton2 = XButton2,
        TaskButton = 0x00000020,
        ExtraButton3 = TaskButton,
        ExtraButton4 = 0x00000040,
        ExtraButton5 = 0x00000080,
        ExtraButton6 = 0x00000100,
        ExtraButton7 = 0x00000200,
        ExtraButton8 = 0x00000400,
        ExtraButton9 = 0x00000800,
        ExtraButton10 = 0x00001000,
        ExtraButton11 = 0x00002000,
        ExtraButton12 = 0x00004000,
        ExtraButton13 = 0x00008000,
        ExtraButton14 = 0x00010000,
        ExtraButton15 = 0x00020000,
        ExtraButton16 = 0x00040000,
        ExtraButton17 = 0x00080000,
        ExtraButton18 = 0x00100000,
        ExtraButton19 = 0x00200000,
        ExtraButton20 = 0x00400000,
        ExtraButton21 = 0x00800000,
        ExtraButton22 = 0x01000000,
        ExtraButton23 = 0x02000000,
        ExtraButton24 = 0x04000000,
        MaxMouseButton = ExtraButton24,

    };
    Q_DECLARE_FLAGS(MouseButtons, MouseButton)

You see several 'alias' names in this list. I advise the following usage:

1: Use 'MiddleButton' instead of 'MidButton'.

2: Use 'BackButton' and 'ForwardButton' -- these names are more widely accepted and used than the alternatives (Xbutton1, Xbutton2, ExtraButton1, ExtraButton2).

3. For all higher buttons, including the so-called 'TaskButton', use the 'ExtraButton_nn' name.

And do remember: This is upcoming in Qt5 ONLY; it will NOT be made available in the Qt 4.x Release Series.

Before I request that this bug be closed (RESOLVED, UPSTREAM), I wish to thank Thiago Macieira -- who's patience made this enhancement possible.

Closed, by me, after making myself the assignee. This capability will be present in the near future, when KDE programs are running against Qt libraries at version 5.x.

resolved/upstream.

This is great news, but should this bug be closed? This bug is not just about getting the mouse buttons recognized. In fact, this was *already* possible with programs like imwheel and keyboard button mapping in KDE.

The real point behind this bug is to make it very, very easy to have users assign these buttons in KDE to useful functions. That is, a button to change forward/backwards through your desktops, a button to move a window forward/backwards through desktops, a button to shade/unshade windows, and so on.

As far as I know, this functionality is not in KDE as of yet. So, this bug should remain open I'd assume.

(not faulting people for the enthusiasm, but the front end existing in KDE to configure this functionality is more than 1/2 of what this bug was about...)

So, put again, how can upstream resolve a bug that has to do with KDE having a friendly GUI to incorporate extra buttons -> window manager operations?

I also think this is not the solution but supporting more hardware buttons is part of another limitation.
Let's imagine a user who has a mouse with "forward-backward" buttons on it and a keyboard also with forward an backward buttons. Neither of them work.
Many other apps (browsers and e.g. the ubuntu software center) don't need special configuration for these keys, they just work. It would be also not appropriate to have to configure this, since the buttons have a strict meaning on them.
The best thing would be just support all "special" buttons side-by-side to what you configured. I guess the scancodes are standardised.
I don't want to be rude but I guess neither of the devs has a mouse or keyboard with "forward-back" buttons. Expecially for web browsing this is very very handy. And work for years...with windows...with gnome...with most webbrowsers...sadly not in kde apps :(

(In reply to comment #37)
> This is great news, but should this bug be closed? This bug is not just about
> getting the mouse buttons recognized. In fact, this was *already* possible
> with programs like imwheel and keyboard button mapping in KDE.
>
> The real point behind this bug is to make it very, very easy to have users
> assign these buttons in KDE to useful functions.

Michael, KDE Bugzilla is "wide open" for comments, and many of these comments (including some which *I* made) ignore an important aspect of bug management procedure:

ONE issue == ONE bug. ALWAYS.

We have several other bugs which touch on "using the mouse", and I'm about to take ownership of (at least!) one of them. I will probably bisect those bugs even more, because nearly all of them involve more than one programming job, and because they're full of comments which ask for unrelated things. Here's an important one, with nearly as many votes as you saw here: https://bugs.kde.org/show_bug.cgi?id=48062. Please take a look. You'll see that the 'description' (the title) asks for one very specific thing, but nearly all of the comments (and even the attachment) are talking about something completely different.

48062 is about defining the mouse button to emulate a modifier key -- and ONLY a modifier key. On your keyboard, the modifiers- Shift, Ctrl, Alt, Meta, Num Lock.... do nothing by themselves. But nearly all of the comments talk about Actions-- which are typically invoked by a Modifier AND ANOTHER KEY, or (as the comments request) a mouse click.

Using a high-numbered mouse button to perform an action (https://bugs.kde.org/show_bug.cgi?id=96431) involves much, MUCH simpler programming. But 48062 could be used to provide instant keyboard layout switching, modifiers which don't even exist on many keyboards (my USA-105 Keyboard has no pre-defined key for MOD3), and better usability for people with damaged hands.

Exanding the shortcut system, to accept single or multiple mouse clicks as Events which invoke user-specified actions, is that 3rd bug, 96431. But this was pre-requisite for both of them: FIRST, we need to be notified of the button Events. That job is done (mostly.... I've still got coding to do on other Qt5 platforms, such as Wayland. I'll be crdating additional Qt bugs for tracking work in those modules). That's why this bug is closed.

Your 'main point of the enhancement', and I strongly agree with you, is (https://bugs.kde.org/show_bug.cgi?id=96431). You may or may not be interested in 48062, which is a lot harder for me to accomplish- and that's exactly why I will start on that one sooner. (As happened with this bug, that solution would lie entirely within Qt.)

If I didn't explain this well, feel free to come right back and ask me some more. OK?

(In reply to comment #38)
> I also think this is not the solution but supporting more hardware buttons is
> part of another limitation.
> Let's imagine a user who has a mouse with "forward-backward" buttons on it and
> a keyboard also with forward an backward buttons. Neither of them work.
> Many other apps (browsers and e.g. the ubuntu software center) don't need
> special configuration for these keys, they just work. It would be also not
> appropriate to have to configure this, since the buttons have a strict meaning
> on them.
> The best thing would be just support all "special" buttons side-by-side to what
> you configured. I guess the scancodes are standardised.
> I don't want to be rude but I guess neither of the devs has a mouse or keyboard
> with "forward-back" buttons.

Hi, Michael!
There are a lot of comments about this, but you don't need to read them all- I wasted MY time for you, so you get only the 'executive summary' ;)

Here, among the KDE people, we strongly agree that 'BackButton' and 'ForwardButton' are widely recognized and used for those purposes. The current names, 'XButton1' and 'XButton2' are cryptic and non-obvious. So, if you look at the actual code in Comment 34, you see that I created new alias names for those buttons.

Following the change to make the button identity obvious to other Developers, our process calls for bugs to be written against the specific programs- not the entire Kdelibs (or Qt, as it ultimately turned out to be.) Konqueror is one of those programs, obviously. File browsers- Krusader and Dolphin together with most any FileChooser pop-up (the code is shared) are another obvious candidate. And Amarok is another: Go "back" to the Previous Track or Scene in the album/movie.

But I won't be writing that code- it gets managed within those specific projects. Different Product == Different Bug.

BTW, my initial reason for doing this was "feature-parity" with GTK+ (the Qt-like library underneath Gnome-2) and the Compiz Window manager. I have had the EXACTLY the same opinion which you have, and our 1419 other voters. Since KDE 4.8is frozen for "new features in the API", you won't be seeing this in the near future. But KDE-Next, in 2012, will have it all.

<joke > BTW, did you just offer to buy me a Razr Naga? If so, I prefer the "molten" look. My current mouse (Logitech 700) has only 14 buttons, and I'm including the 4 tilt wheel directions in that count. Need Razr! < /joke >

Re-opening since this is a reasonable request. Binding shortcuts/actions to additional mouse buttons seems reasonable.

Even if there's no explicit Qt support (is this still true?) we could still implement it ourselves on the KDE side.

*** Bug 272728 has been marked as a duplicate of this bug. ***

*** Bug 386670 has been marked as a duplicate of this bug. ***

*** Bug 424369 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #41)
> Re-opening since this is a reasonable request. Binding shortcuts/actions to
> additional mouse buttons seems reasonable.
>
> Even if there's no explicit Qt support (is this still true?) we could still
> implement it ourselves on the KDE side.

I'm not much of a programmer. It seems that KGlobalAccel would need some new member function signatures, creating a bit of a mess for backward compatibility. Or, would it be better to create an entire new class for "KGlobalMouseAccel" ?

(In reply to Nate Graham from comment #41)
> ....
> Even if there's no explicit Qt support (is this still true?) we could still
> implement it ourselves on the KDE side.
I should note that Qt support is explicitly "good" for X11, and Wayland seems ready for up to 16 buttons. The reasons why I should no longer be the assignee are (1) the fact that I am unqualified to make the 'visionary' choices: which buttons should default to which actions; and (2) the glue which must hold it together (clicks -> signals and slots for "actions") and (3) making coherent updates for all of the programs which should perhaps make use of higher-numbered buttons.

(removed myself as assignee)

Twenty years later and this is still unresolved?

Going to System Settings > Input Devices > Keyboard > Advanced > Swap ESC and Caps Lock is a piece of cake.

Then going to System Settings > Input Devices > Mouse there is nothing for changing e.g.
Wheel Down > Screen down
Wheel Up > Screen up
Button Forward > Control + Left click
Button Back > Shift + Left click

(In reply to Rob Kam from comment #48)
> Twenty years later and this is still unresolved?
>
> Going to System Settings > Input Devices > Keyboard > Advanced > Swap ESC
> and Caps Lock is a piece of cake.
>
> Then going to System Settings > Input Devices > Mouse there is nothing for
> changing e.g.
> Wheel Down > Screen down
> Wheel Up > Screen up
> Button Forward > Control + Left click
> Button Back > Shift + Left click

Well, when you're on Wayland, there is actually an interface for setting up the additional mouse buttons, but it only works for extra mouse buttons (10+) and not for those that are mapped by default (1-9).
And at least with the current versions even that is broken, e.g. you can assign a keypress event to a mouse button, but it won't work.
In principle if you would like to reassign buttons 8 (back) and 9 (forward), you could remap your mouse so that these are e.g. button 11 and 12 and then you should be able to reassign them to a keyboard combination you could then use. I haven't checked though whether this works, because as mentioned above it's broken.
And it should be possible to directly assign mouse buttons in khotkeys (bug 96431).

But in general I agree, it should be possible in the kcm to remap mouse buttons to different functions or even a key combination.
I would like to have a list of detected mouse buttons, each with a dropdown list and a couple of predefined mouse actions, e.g. the default mouse actions + selected commands (like those listed for the screen edges), e.g. present windows, peek at desktop, activity manager, close tab …
And as the final settings I would like to have "Mouse button 10" (if it's button 10) or "Use as hotkey", so that it can be assigned to any (possibly program-dependent) hotkey function and "Key combination".
Of course that also means that there is some duplication in the functionality, but I think it would be nice to present a selection of predefined commands to the user.

For me, these possibilities are – together with the problem of restarting kwin – the main showstopper to switch to Wayland.
On X11, I'm using imwheel, but that doesn't work on Wayland anymore. There are some options out there to get something like imwheel on Wayland, too, but they basically require working around the compositor and usually are way more complicated to setup, so I really would like to avoid those.
Plus, I think in 2023, it should be really possible to properly setup your mouse in KDE without needing to fall back to 3rd party programs. :/

As this has been mentioned you can now bind arbitrary key combinations to extra mouse buttons. I just tested it and it works fine for (bound printscreen to a side button for testing). So I am closing this as resolved. If it doesnt work for people (as it seems to not do for Bernd) please file a new bug

This bug is about being able to bind any action *at all* to the mouse buttons, in X11/xorg, not binding mouse buttons to a key.

The prior to responses to this bug, prior to closing, expressed that there was no resolution at all to this bug. So, were you able to;

- change workspaces by binding a mouse button, without any additional software (no imwheel!)?

- perform any action you can bind a key to? That is, if I can bind a key combo to "minimize window", can I bind a mouse button to that?

- change all other buttons already mosue mapped? eg, change from wheel movements to side buttons, or button 11, or whatever, workspace up/down?

I don't believe you've read and understood this bug.

Additionally, do note -- what is the scope here? Are there global, and window specific settings? For example, does "bind button 11 to 'move forward to next workspace', mean that this is taken no matter if the mouse is hovering over the desktop, or a window?

Most of those actions are exposed globally, and either have a keyboard shortcut bound to them by default, or you can bind one yourself. And you can also assign arbitrary shell scripts to global keyboard shortcuts. Then you can bind a mouse button to the keyboard shortcut used to trigger any of those actions. So the ability is there.

(In reply to Nate Graham from comment #53)
> Most of those actions are exposed globally, and either have a keyboard
> shortcut bound to them by default, or you can bind one yourself. And you can
> also assign arbitrary shell scripts to global keyboard shortcuts. Then you
> can bind a mouse button to the keyboard shortcut used to trigger any of
> those actions. So the ability is there.

Wouldn't binding a keyboard button to a mouse button, followed by an action to a keyboard button, be considered a workaround? The original bug report seems fairly clear.

(In reply to miranda from comment #54)
> Wouldn't binding a keyboard button to a mouse button, followed by an action
> to a keyboard button, be considered a workaround? The original bug report
> seems fairly clear.

Yes, that works. It would still be a good thing if mouse buttons could be assigned directly, so you can avoid having to assign a key (combination) to that button. Personally, I think that it should not matter to the DE whether a button event was triggered by a mouse button and key presse or even a button press by a game controller.

The current implementation works sufficiently to cover the needs of most, I guess, but there are limitations, e.g.:
- Combining Modifiers with mouse buttons might not work, as most of the time you'd want to assign a key combination to the mouse button and not a single key stroke. e.g. you assign Meta+F1 to button 7, but then you can't use Meta+button 7 for other things.
- The configuration is not device-specific. There surely are arguments pro and con this, but if you are using multiple mice, it might not make sense to assign button 7 to the same key combination on both devices, since they could be located at completely different positions
- Currently, it'll only search the first level for a key, which can lead to unwanted effects, if you're not using a standard layout or trying to access positions that are not on the first level on the standard layout. I created a bug for this, but it's not been fixed yet.

(In reply to David Redondo from comment #50)
> As this has been mentioned you can now bind arbitrary key combinations to
> extra mouse buttons. I just tested it and it works fine for (bound
> printscreen to a side button for testing). So I am closing this as resolved.
> If it doesnt work for people (as it seems to not do for Bernd) please file a
> new bug

I experienced two bugs with this, one of which has been fixed, but the other one is still open.
Nevertheless, I can use it, working around the limitations of the current system, and have been doing so for more than half a year now on Wayland exclusively without using imwheel or similar.

(In reply to Bernd Steinhauser from comment #55)
> Yes, that works. It would still be a good thing if mouse buttons could be
> assigned directly, so you can avoid having to assign a key (combination) to
> that button. Personally, I think that it should not matter to the DE whether
> a button event was triggered by a mouse button and key presse or even a
> button press by a game controller.

Apologies if I wasn't clear, that was in response to Nate - I agree with you here. A workaround is just that, a workaround, meaning from my perspective the feature request should still be open.

(In reply to miranda from comment #56)
> (In reply to Bernd Steinhauser from comment #55)
> > Yes, that works. It would still be a good thing if mouse buttons could be
> > assigned directly, so you can avoid having to assign a key (combination) to
> > that button. Personally, I think that it should not matter to the DE whether
> > a button event was triggered by a mouse button and key presse or even a
> > button press by a game controller.
>
> Apologies if I wasn't clear, that was in response to Nate - I agree with you
> here. A workaround is just that, a workaround, meaning from my perspective
> the feature request should still be open.

I think it's ok if this one is closed, but as a mid- to long-term goal, it should still be on the list in my opinion.
It might be helpful though to put that into a new feature request outlining the problems and goals more precisely.

We're open to improving the UX in the future to allow directly triggering exposed global actions, rather than just keyboard shortcuts. But that's an improvement for the existing feature, so I'd recommend that someone submit a new feature request Bugzilla ticket to track it. :)