KDE Mouse Config GUI (for Todd and Aaron)

[Rick Stockton]

> On Friday, February 4, 2011, todd rme wrote:
>> I don't want to sound like a broken record here, but this is exactly
>> the sort of problem that being able to use mouse buttons in keyboard
>> shortcuts would solve.  Why create an entirely new GUI for this when
>> we already have a GUI that can do this, and far more, and that users
>> are already familiar with?
> is that a different problem?
This is not a "different" project/problem. Rather, it's a previously 
unexpected 'sub-task' within the bigger project.

The big project, Todd, is exactly the one you describe: Provide support 
for using all these "gamer" mouse buttons into
the KDE shortcut widget, and underlying Qt event and signal library.

But- Qt doesn't support button numbers above "Button8", and KDE doesn't 
take advantage of anything above "Button5" (i.e., the vertical wheel 
events). In adding this support, Qt has hard-coded that tilt-wheel 
"Scroll Left" and Scroll Right" **MUST** come from the hardware as 
"Button6" and "Button7". Tilt wheels don't actually have a wheel, with 
which can control the amount of distance. Instead, they send ButtonPress 
very rapidly, emulating a continuous spin for as long as you hold that 
button down.

With a "regular button", if you press and hold it down, there are no 
interrupts at all until you let go. But that't not how Tilt wheels work. 
The emulation, in hardware, consists of Rapid ButtonPress events (at 
least 20/second is typical), for as long as you hold it in the tilted 
position. Qt knows that the scroll wheel emulation needs special 
treatment- and does it pretty well, making sure that a matching 
ButtonRelease evt. is provided at the end even if the mouse didn't send 
it, and vastly compressing the number of interrupts into higher code.

But a Mouse which implements on Button12/13 rather than the expected 
Button6/Button7, will likely all kinds of breakage. (The Qt guys have 
not attempted to support numbers that high-- yet. That's my first job 
:)) We'll see the original rate of ButtonPress events, but (possibly) 
without matching ButtonRelease. CPU Utilization goes wild with all the 
interrupts (worse if they provoke re-paints, and, depending on the 
singals being listened for, they might be interpreted as either 10 
double-clicks per second OR twently single clicks per second... Or it 
might simply break, because we never got matching ButtonRelease Events. 
(I don't know exactly what will happen; maybe a wide variety of 
different things. But they're all going to be VERY bad.)
- - - - -

> on Friday, February 4, 2011, Aaron wrote:
>
> if understand correctly, the problem Rick is attempting to solve is this:
>
> * i plug in fancy mouse a (FM(a)) and use button N to trigger an action
> * i unplug FM(a) and plug in FM(b), which unfortunately maps the same buttons
> (to the user) to different codes (to the computer)
>
> with Rick's proposed solution, the user wouldn't notice a difference between
> the two mice ... as expected.
>
> Rick: am i understanding you correctly here?
Aaron: yes that's an intended result. But the critical need is a solution for to make ALL mis-numbered horizontal wheels appear as Button6/Button7. When a user plugs starts up KDE with a mouse we don't already know about, via<device name>, then we need to provide a way for s/he to show us which the buttons which need to be mapped into this standardized pair. ("Please press and hold the button which you would like to use as "scroll left".) For the UI, this should be done as an enhancement to the current "Left or Right Handed?" Mouse configuration. (That's because all of the surrounding Doco and programming structures are already present, we simply expands them)

Thanks for allowing solution at the X11 layer. Button re-numbering via xinput set-button-map DOES work for the wheels (I checked before writing yesterday's initial entry on the subject). And the within-Qt alternative would be quite nasty. :((