KDE MouseConfig GUI (back to Aaron)

[Rick Stockton]

I'm making replies to some of those first responses (thank you all!).

I asked: Should we push that user-specified map into Qt (i.e., with new 
interfaces and variables to handle any necessary "fixes" for left/right 
wheel assignments) -- or push it all the down into X11?
> Aarron said: if possible, that would be great imho.
Easy- but for code clarity and ease of maintenance, I'd want to break 
the "interface through Qt only" rule. (If we're pushing the assignment 
of these hardware property changes down to X11 anyway, it would be silly 
to stick a lot of changes into Qt for the mere purpose of accomplishing 
the hand-off.)
> Aarron said: is it possible to identify these mice when they are 
> plugged in, and if so -- could we build a list of "known" mice with 
> optimal default button maps?
Also quite easy. And there have been projects to control mouse 
properties in the past (for Logitech in particular, and IIRC, licensed 
under GPLV2.), so we might be able to learn the properties of many 
models by simply reading code... without a going to the trouble of 
actually acquiring them. Doco should also invite people to open a bug if 
they've figured out the "optimal" map for a mouse which isn't already in 
the table, allowing us to expand it over time.

When a mouse core pointer device is removed and replaced by another, I'm 
absolutely certain that X11 gets an interrupt from UDEV. (That's what 
provokes it to implement matching device class definitions). I think 
that it has to get interrupts from HAL, as well... but I'm not totally 
sure how ask for notification of a mouse removal into higher level code. 
But Alan Coopersmith (et. all) can probably tell me their "best way" 
without even thinking about it; if there's no objections to the 
following design, then I'll go ahead and ask on one of the two X11 lists.

So, here's my tentative design: At KDE startup, do an "xinput list 
--short" and grep for pointer device names. Then, if we ALREADY have a 
matching [device-name] section in our config file (maybe with filename 
"./kde/share/conf/mousebuttonconfigs.rc"), and the device is enabled, 
execute "xinput set-button-mapping" with the values in the file stored 
for that device. Here's an optional add-on, and my vote would be to do 
this as well:

Perform an "xinput get-button-map" first. If the order received doesn't 
already agree with with the order we intend to assign, save it in a $TMP 
and restore it session termination. That way, we don't inflict our 
settings on Gnome (in the same way that Gnome likes to inflict it's 
settings, e.g. Keyboard, on other environments by scribbling them 
directly into xorg.conf).

As most of you know already, this becomes extendable after we implement 
the buttons: Other tunable properties like "deceleration" and "reporting 
rate" are provided into UDEV by many mice, and there are usually 
interfaces for things like axis-swapping too.

Or, would you guys prefer to leave our mapping in place after the KDE 
Session terminates?