Bug 99044

Summary: Undesired drags when tap-to-click is enabled
Product: Wayland Reporter: Freeroot <free.r>
Component: libinputAssignee: Peter Hutterer <peter.hutterer>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium CC: peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: evemu-record

Description Freeroot 2016-12-10 11:55:04 UTC 
Hello,

I use my touchpad with functionality tap-to-click but, instead of clicking, the behavior of my tap is often considers as a dragging.

For example, when I select a folder, most of the time the folder is dragging whereas just selected or when I want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas.

I found the configuration option tap-and-drag but it's not already implemented in Wayland and I can't use it like in Xorg. I would like to implement it in Wayland but people told me to try to manage my issue with libinput directly too (https://bugzilla.gnome.org/show_bug.cgi?id=775756).

After careful consideration, people here can surely help me to improve my drags and delete my undesired drags instead of trying to disable it.

I can provide all needed information.
Comment 1 Freeroot 2016-12-19 11:12:37 UTC 
Maybe there is something to do with the drag timeout defines line 39 of evdev-mt-touchpad-tap.c ? :

#define DEFAULT_DRAG_TIMEOUT_PERIOD ms2us(300)
Comment 2 Peter Hutterer 2016-12-20 03:48:00 UTC 
That timeout is the time until we considered a drag over, i.e. once you are dragging and release the pointer, this time decides when we send the matching up event to stop the drag process. Otherwise, a short up and down again will continue the drag process. This makes it possible to drag larger distances.

In your case, the issue is that it's detected as dragging when it shouldn't be, so by the time this timeout takes effect we've already done the wrong thing anyway.

Please record one of these failed tap sequences with evemu-record and attach the output here.
Comment 3 Freeroot 2016-12-20 11:08:13 UTC 
Created attachment 128577 [details]
evemu-record
Comment 4 Freeroot 2016-12-20 11:27:06 UTC 
I want to precise the behavior of tapping and dragging for me.

(1) If I tap and let my finger on the touchpad : nothing happens. (Because it lets the possibility to move the cursor without a new seletion)
(2) If I tap and raise my finger after a few : it's a click.
(3) If I tap and raise my finger after a long time : nothing happens.

So, to click somewhere, I need to tap and raise my finger quickly.

(4) If I tap to click (2) and I reput my finger on the touchpad to move the cursor after a long time : the cursor moving without a drag.
(5) If I tap to click (2) and I reput my finger on the touchpad to move the cursor after a few : it's a drag.

(4) and (5) are like a double click but with a finger keep on the touchpad after the second tap.
(If I do a double click and then I reput my finger on the touchpad after a few, it's a drag too, a sort of triple click with a finger keeps on the touchpad after the third tap).

It's the (4) case which is an issue for me because I need to wait for a long time to avoid the drag.
Comment 5 Freeroot 2016-12-20 11:50:56 UTC 
Sorry, the case (5) is my issue because I must wait after a click to move the cursor.
Comment 6 Peter Hutterer 2016-12-21 02:57:42 UTC 
oh, ok, then I misunderstood the actual issue. I thought the issue was in (2), i.e. a tap triggering a drag due to some motion events. Your description sounds like everything is indeed working as expected and you need to turn the tap dragging off. which we already have a toggle for, so I have to punt you back to gnome, sorry about that.
Comment 7 Freeroot 2016-12-21 09:31:17 UTC 
Don't be sorry, some investigation were necessary because I didn't understand very well what happened. yes, libinput is already good.

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.