KDE MouseConfig GUI (back to Aaron)
rickstockton at reno-computerhelp.com
Sun Feb 6 03:38:38 CET 2011
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
> 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
More information about the Plasma-devel