On mice with more than 3 mouse buttons the next 4 additional buttons are inaccessible due to the default ZAxisMapping. As we do not want to change the ZAxisMapping (buttons 4-7 are configured as mouse wheel events by most applications by default), we need an input mapping of the mouse buttons to higher button numbers.
Created attachment 3651 [details] [review] Patch for adding a ButtonMapping option This patch adds a ButtonMapping option which allows to define arbitrary button mappings (including left-handed mouse etc.). The default '1 2 3 8 9 10 11 ...' is suited to circumvent the ZAxisMapping problem. The patch also fixes some bugs that were encountered during this work, e.g. ZAxisMapping "1 2" (while not being usefull at all) would typically map the wheel to Buttons 2 and 3. The reverseMap was of size 32, of which the top 16 values would never be addressed. Hardware state decision was done on button save state that included ZAxisMapping, but not button reordering. The patch changes the size of MouseDevRec, so I'm not exactly sure whether I have to increase OS_MOUSE_VERSION_MINOR. Please comment!
*** Bug 1900 has been marked as a duplicate of this bug. ***
Created attachment 3755 [details] [review] Updated patch This update adds a man page entry and has some changes for better ABI backward compatibility.
Included in CVS head.
Sorry, I have issues with this patch: 1. It breaks wsmouse on OpenBSD and NetBSD, because the code initializing the default pMse->buttonMap is not called when an OS-specific preInit functions is used 2. I wonder if the MMHIT protocol changes at the end of the patch (which also got committed) belong to the change discussed here.
Created attachment 3773 [details] [review] Proposed fix: move buttonMap initialisation before calling OS specifix PreInit
You're perfectly right. This should be fixed.
Created attachment 3774 [details] [review] Proposed fix 2: Change ButtonMapping default As discussed in the xorg mailing list: The ZAxisMapping has been set default to "4 5 6 7" again, so the ButtonMapping default should be changed from the one-to-one mapping to "1 2 3 8 9 10 11..." as well.
I found this problem as well last night on Solaris when using USB mice which go through the OS-specific mouse code, and neither of these patches fix it, since the buttonMap is only initialized when "ButtonMapping" is set in the config file, since otherwise, the default is NULL and if s is NULL, it skips initializing the button map altogether: s = xf86SetStrOption(pInfo->options, "ButtonMapping", NULL); Should there be a different default if unset? Or should there be a default fallback if s comes back as NULL?
Comment on attachment 3773 [details] [review] Proposed fix: move buttonMap initialisation before calling OS specifix PreInit Never mind, I misapplied the patch - after looking more carefully and applying patch from attachment #3773 [details] [review] correctly, I agree that does look correct and fixes my problem on Solaris, so I'm approving it for checkin to 6.9/7.0 now. Please go ahead and commit.
Comment on attachment 3774 [details] [review] Proposed fix 2: Change ButtonMapping default Approving patch from attachment #3774 [details] [review] as well. Please commit.
Applied to CVS.
*** Bug 4504 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.