After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638973 - Tap-to-click does not handle unusual button maps
Tap-to-click does not handle unusual button maps
Status: RESOLVED DUPLICATE of bug 635486
Product: gnome-settings-daemon
Classification: Core
Component: mouse
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks: 598820
 
 
Reported: 2011-01-08 08:52 UTC by Yuri Khan
Modified: 2011-03-21 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[1/2] mouse: Extract get_device_button_mapping function. (3.22 KB, patch)
2011-01-08 08:57 UTC, Yuri Khan
none Details | Review
[2/2] mouse: Fully take button mapping into account when setting tap-to-click. (7.49 KB, patch)
2011-01-08 08:59 UTC, Yuri Khan
none Details | Review

Description Yuri Khan 2011-01-08 08:52:22 UTC
While developing a patch for bug 598820, I found the following behavior (introduced in commit 46dee1da on 2009-10-26 by Peter Hutterer):

When the [x] Enable mouse clicks with touchpad checkbox is toggled on, gnome-settings-daemon always assigns button 1 or 3 to one-finger tap and 3 or 1 to two-finger tap, depending on the Mouse Orientation setting. This is intended to reverse the X button mapping which normally maps 1 to 1 and 3 to 3, but switches them around for Left-handed mouse orientation.

Right-handed:
One-finger tap -- physical button 1 (left) -- logical button 1 (primary)
Two-finger tap -- physical button 3 (right) -- logical button 3 (secondary)

Left-handed:
One-finger tap -- physical button 3 (right) -- logical button 1 (primary)
Two-finger tap -- physical button 1 (left) -- logical button 3 (secondary)

So taps always map to the primary and secondary logical buttons.

This works as intended in the simple case when the X button map is only changed by the gnome-settings-daemon itself, which is limited to these two maps -- identity for right-handed and "swap 1 and 3" for left-handed.

However, as soon as the user sets a non-trivial button map where the values 1 and 3 are not on their usual places, taps will not map correctly.

Example: The user has a touchpad with hardware left and right buttons, and since he is accustomed to taps always mapping to primary and secondary buttons, wishes to use the hardware buttons to navigate Back and Forward in browser. He invokes xinput set-button-map to install the following button map: 8 2 9 4 5 6 7 1 3 10 11 12 (swapping 8/1 and 9/3).

Expected behavior:
Left hardware button -- physical button 1 -- logical button 8 (Back)
Right hardware button -- physical button 3 -- logical button 9 (Forward)
One-finger tap -- [...] -- logical button 1 (primary)
Two-finger tap -- [...] -- logical button 3 (secondary)

Actual behavior:
Left and right hardware buttons -- as expected
One-finger tap -- physical button 1 -- logical button 8 (Back)
Two-finger tap -- physical button 3 -- logical button 9 (Forward)

To do the right thing, g-s-d needs to analyze the current X button map, search it for the values 1 and 3, and pass the appropriate indexes to the "Synaptics Tap Action" property. A patch follows.
Comment 1 Yuri Khan 2011-01-08 08:57:58 UTC
Created attachment 177809 [details] [review]
[1/2] mouse: Extract get_device_button_mapping function.
Comment 2 Yuri Khan 2011-01-08 08:59:12 UTC
Created attachment 177810 [details] [review]
[2/2] mouse: Fully take button mapping into account when setting tap-to-click.
Comment 3 Peter Hutterer 2011-01-31 05:20:25 UTC
Review of attachment 177809 [details] [review]:

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Comment 4 Peter Hutterer 2011-01-31 05:23:07 UTC
Review of attachment 177810 [details] [review]:

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Comment 5 Bastien Nocera 2011-02-19 04:02:14 UTC
I'd rather this be handled by the work in bug 635486.
Comment 6 Bastien Nocera 2011-03-21 14:16:37 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 635486 ***