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? _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
