[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 34362] support for additional mouse buttons
From:       rickst29 <rickstockton () reno-computerhelp ! com>
Date:       2010-12-08 7:14:06
Message-ID: 20101208071406.77AFC76F2C () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=34362


rickst29 <rickstockton@reno-computerhelp.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rickstockton@reno-computerh
                   |                            |elp.com




--- Comment #28 from rickst29 <rickstockton reno-computerhelp com>  2010-12-08 08:13:59 ---
(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
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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]