No way to configure mouse button number

Bug #62949 reported by Damien Cassou on 2006-09-29
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
kdelibs
Won't Fix
Wishlist
gnome-control-center (Ubuntu)
Wishlist
Unassigned
gnome-system-tools (Ubuntu)
Medium
Unassigned
kde4libs (Ubuntu)
Wishlist
Unassigned

Bug Description

Using kde-systemsettings, I can't configure my 6 button mouse. It would be interesting to just have a way to say "this mouse has X buttons".

(*** 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?

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Changed in kde-systemsettings:
status: New → Incomplete
Damien Cassou (cassou) wrote :

I'm on Ubuntu Gutsy with Gnome right now. There is still no way to graphically configure my mouse, i.e., without modifying Xorg.conf. I don't know about KDE however.

Changed in kde-systemsettings:
importance: Undecided → Medium
status: Incomplete → Confirmed
Endolith (endolith) wrote :

Should a separate bug be filed for GNOME settings? The GNOME mouse settings window really needs a way to configure >3-button mice, for all configurations that can't be auto-detected (from USB VID/PID, etc.)

No, I mark this bug also in gnome-system-tools but i don't really know if this is the right package. When not please change it.

Changed in gnome-system-tools:
status: New → Confirmed
importance: Undecided → Medium

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.

Changed in kdebase-workspace:
importance: Medium → Wishlist
status: Confirmed → Triaged
Changed in kdelibs:
status: Unknown → Confirmed

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).

Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-control-center (Ubuntu):
importance: Undecided → Wishlist

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.

Jonathan Thomas (echidnaman) wrote :

Hi there,
The Kubuntu bug squad is in the process of closing wishlist items that have already been reported at KDE. Don't worry, your issue still is being tracked at KDE's bug tracker at: http://bugs.kde.org/show_bug.cgi?id=34362 . It's just that Kubuntu currently does not have the manpower necessary to take this feature on ourselves. We will receive this functionality once KDE implements it in one of their releases.

Thanks for understanding, and have a nice day.

Changed in kde4libs (Ubuntu):
status: Triaged → Won't Fix

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.

Download full text (4.7 KiB)

(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...

Read more...

(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. :((

Changed in kdelibs:
importance: Unknown → Wishlist

*** 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 >

Changed in kdelibs:
status: Confirmed → Won't Fix
Changed in gnome-control-center (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.