(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 <> 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 events directly. And the API only shows the bit mask, which everyone knows to be grossly inadequate. (Xorg developers discuss the need for a wider bit-mapped field in a future offering they label as "X12", it will provide for a mask of at least 32 buttons- maybe 64). But don't hold your breath, this won't happen for years. In the meantime, it seems like qt gets "dragged" into supporting just one or two more buttons every year or two, on the basis of some "critical" application requirement (e.g., Firefox). qt-X11 leads should, IMO, stop adding "more buttons" one or two at a time. If they re-do the API to support *ALL* of the buttons which the platform presents for a 2D pointer device, they'll prevent huge amounts of ongoing pain. In the case of X11, qt could easily run this specific query, and it should be re-worked to provide the press/release events which X11 is capable of emitting. This is an API change, of course, and could be done in several ways. All of these "gamer" mice, were built for MS-Windows first. qt on MS-Windows, and KDE on Windows, can support them with the same API, "hiding" the lower-level details inside the qt-to-platform runtime I/O interface. Now I have a question for Stephan, or any other KDE persons who might take ownership of this long-standing design defect. (de-facto in KDE, de-jure in qt.) Who takes the lead on creating a discussion of requirements for the implementation which KDE needs from qt? I'm not an idiot, but I've never worked within any "open software" community... I'd be better as a commentator and coder, not so good as a TEAM LEADER.