GNOME Bugzilla – Bug 591696
Multitouch touchpad acts as non-multitouch AFTER gdm
Last modified: 2010-01-09 10:56:10 UTC
Please describe the problem: My touchpad on my EEEPC 901go is multitouch enabled. In current Ubuntu 9.10 development release this works in gdm's login window. If I start a GNOME-session, the touchpad switches to single touch mode. If i choose to start a xterm session the touchpad works just fine. Steps to reproduce: 1. grab a livecd from http://cdimage.ubuntu.com/daily-live/current/ 2. boot it and use two fingers and try to scroll up and down (does not work; mouse moves) 3. install using this image, boot into gdm. see it working here correctly. 4. log in: You have a single touch touchpad now Actual results: Expected results: Does this happen every time? yes Other information: first reported here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/413050
Probably something to do with the new g-s-d module to configure touchpads.
So, what does the touchpad preferences panel say (System->Preferences->Mouse)?
There is a new menu point "scrolling" witch was set to "Edge scrolling". Setting it to "Two-finger scrolling" enables multitouch scrolling. Now I can enable multi-finger tapping. Two-finger tap is right right click and three-finger tap is middle click: They were switched. Is this intentional? I really liked it before because I have to really concentrate to do a proper three-finger tap so I want this to be a less often used button (right) and not the often used middle-click.
No idea, really. CC'ing Peter, he should know.
"switched"? the upstream driver uses a 1/3/2 mapping and the patch to add it to gnome had the same mapping (see Bug #578444). The reason for the 1/3/2 mapping instead of 1/2/3 is that - as you say - a three-finger tap is harder to execute than a two-finger tap. In the GUI we currently have, left and right clicks are required, the middle-click is handy but optional. This is a point for making the two required ones as the easier ones to trigger. If there are devices that support two-fingers but not three (I don't know if there are, the synaptics driver supports them though) then these devices still had access to left/right clicks. I believe it also replicates the OS X behaviour which users may be familiar with, possibly windows too but I'm not sure about that.
(In reply to comment #5) > "switched"? the upstream driver uses a 1/3/2 mapping and the patch to add it to > gnome had the same mapping (see Bug #578444). > > The reason for the 1/3/2 mapping instead of 1/2/3 is that - as you say - a > three-finger tap is harder to execute than a two-finger tap. In the GUI we > currently have, left and right clicks are required, the middle-click is handy > but optional. This is a point for making the two required ones as the easier > ones to trigger. > Taps are "handy but optional". On that basis, it makes sense to ask how people actually use the tap mechanism (rather than use some academic rationale). Most touchpads come with 2 buttons (lets ignore the minority Mac case for the moment). These map to left and right. This means on most touchpads, there is no middle mouse button. There is a commonly used left button and a relatively rarely used right button. It makes sense that 1 finger should map to left button as this is the vast majority of clicks. However, since there is no middle click (except emulated) it is perfectly reasonable from an academic perspective to make it the next priority in assigning the number of fingers to click it. Anecdotally, this is reflected in how I use my touchpad: tap 1 finger to left click, tap 2 fingers to middle click and right button with thumb to right click. Swapping the number of fingers to click totally breaks this. In fact, for me it is worse than that, as I have a third finger that is incapable or tapping due to an injury. Also, you shouldn't underestimate the value of middle click, particularly in click to paste (used all the time) and middle click to open links (also used all the time). Both of these are, in my view, as important as left click (which can also generally be done through menus, key bindings etc). The reason middle click inherited these capabilities is because the are *very useful*. > If there are devices that support two-fingers but not three (I don't know if > there are, the synaptics driver supports them though) then these devices still > had access to left/right clicks. > > I believe it also replicates the OS X behaviour which users may be familiar > with, possibly windows too but I'm not sure about that. What about the Gnome users? Is what they are familiar with irrelevant?
(In reply to comment #6) > Taps are "handy but optional". On that basis, it makes sense to ask how people > actually use the tap mechanism (rather than use some academic rationale). yes, please do so and let me know. I'm quite happy to change it provided the data but right now it's all anecdotal and since I'll have to defend whichever default comes next I'd rather have some data to back it up. > Most touchpads come with 2 buttons (lets ignore the minority Mac case for the > moment). These map to left and right. This means on most touchpads, there is no > middle mouse button. There is a commonly used left button and a relatively > rarely used right button. It makes sense that 1 finger should map to left > button as this is the vast majority of clicks. However, since there is no > middle click (except emulated) it is perfectly reasonable from an academic > perspective to make it the next priority in assigning the number of fingers to > click it. I take that argument but we now have two IMO good reasons for different defaults. Which justifies a configuration option, but I'm still wary about changing the default. > > I believe it also replicates the OS X behaviour which users may be familiar > > with, possibly windows too but I'm not sure about that. > > What about the Gnome users? Is what they are familiar with irrelevant? I don't know what they're familiar with and to my knowledge no study has been conducted yet to show that. The same is valid for the OS X example I mentioned though I used the term "may" and it wasn't the reason for the choise - the upstream defaults and the argument outlined in comment 5 were.
(In reply to comment #7) > (In reply to comment #6) > > Taps are "handy but optional". On that basis, it makes sense to ask how people > > actually use the tap mechanism (rather than use some academic rationale). > > yes, please do so and let me know. I'm quite happy to change it provided the > data but right now it's all anecdotal and since I'll have to defend whichever > default comes next I'd rather have some data to back it up. > What sort of data would be acceptable? I'm aware that any kind of web poll would be prone to selection bias. I'm not really in a position to do a large scale user survey (although I'll ask around my lab :). <snip> > > What about the Gnome users? Is what they are familiar with irrelevant? > > I don't know what they're familiar with and to my knowledge no study has been > conducted yet to show that. The same is valid for the OS X example I mentioned > though I used the term "may" and it wasn't the reason for the choise - the > upstream defaults and the argument outlined in comment 5 were. Given no data, is it not reasonable to assume that users get used to what they have? i.e. the default up until now (which was certainly the other way around and I believe is imposed by the synaptic driver). I do understand your position, but it seems that you have *already* changed the default, hence all these bug reports.
This bug and bug #598820 and bug #589944 seem the same to me....
*** This bug has been marked as a duplicate of bug 589944 ***