Bug 104659

Summary: drag-and-drop with physical buttons starting on software button area
Product: Wayland Reporter: Carlo Caione <carlo>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: benjamin.tissoires, peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: zyrex_clickpad_2_fingers_evemulog
zyrex_clickpad_2_fingers_evemulog_2
zyrex_hid_log
zyrex_hid_log_2

Description Carlo Caione 2018-01-16 18:01:16 UTC
In Endless we are working with several laptops with a clickpad (INPUT_PROP_BUTTONPAD is correctly set). Everything works as expected and the behaviour is the one described in the documentation. Still there is one particular case where the standard behaviour feels "wrong". And we are not sure if this is an expected behaviour or some kind of bug.

The case is the one where the user wants to perform a drag and drop using the physical button (beneath the surface of the touchpad) starting in the software button area. In this case what is happening is that the cursor doesn't move at all, even when the finger is moved out of the button area (never loosing contact with the touchpad).

When the first click for the drag-and-drop is performed outside of the button area everything works as expected.

Is this expected somehow?

Thanks!
Comment 1 Peter Hutterer 2018-01-21 23:43:11 UTC
yeah, it's a side-effect of the data we see when pressing a button. As you press down, your finger flattens, causing the center of the touch to move as seen by the touchpad. The software buttons are a dead zone for that reason, otherwise we see slight pointer movements on every button press/release, causing users to miss the click targets.

There's probably something more fine-grained we could implement but meanwhile we've just been telling users to use one finger for click, another one for pointer movement. That is likely to feel more natural and provides for better control than having to push down while moving.
Comment 2 Carlo Caione 2018-01-21 23:53:30 UTC
(In reply to Peter Hutterer from comment #1)
> yeah, it's a side-effect of the data we see when pressing a button. As you
> press down, your finger flattens, causing the center of the touch to move as
> seen by the touchpad. The software buttons are a dead zone for that reason,
> otherwise we see slight pointer movements on every button press/release,
> causing users to miss the click targets.
Hey Peter,
thank you for your reply. This makes perfectly sense.

> There's probably something more fine-grained we could implement but
> meanwhile we've just been telling users to use one finger for click, another
> one for pointer movement. That is likely to feel more natural and provides
> for better control than having to push down while moving.
Oh ok, this is new to me because on the laptops with a clickpad using two fingers (one for click and the other one for pointer movement) is not working (the cursor doesn't move at all when moving the second finger). Is this behavior working on libinput out-of-the-box or must be enabled somehow? Just to understand if we are hitting a bug on our hardware.

Thanks,
Comment 3 Peter Hutterer 2018-01-22 00:13:38 UTC
Definitely works here, but it *may* not work depending on your hardware (some missing features/older hardware/...). An evemu-record should confirm this.
Comment 4 Carlo Caione 2018-01-22 10:07:18 UTC
Created attachment 136889 [details]
zyrex_clickpad_2_fingers_evemulog

This is a first log taken on a Zyrex laptop with a clickpad when one finger is clicking in the software area button (left button) and the other one is moving on the surface.

The net result on this laptop is that the cursor is not moving at all.
Comment 5 Carlo Caione 2018-01-22 10:08:18 UTC
Created attachment 136890 [details]
zyrex_clickpad_2_fingers_evemulog_2

Another recording (just in case).
Comment 6 Peter Hutterer 2018-01-22 10:45:16 UTC
Your kernel driver is buggy:

E: 0.468061 0001 0110 0001      # EV_KEY / BTN_LEFT             1
E: 0.468061 0001 0110 0000      # EV_KEY / BTN_LEFT             0
E: 0.468061 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +8ms
E: 0.476060 0001 0110 0001      # EV_KEY / BTN_LEFT             1
E: 0.476060 0001 0110 0000      # EV_KEY / BTN_LEFT             0
E: 0.476060 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +8ms

On every hw event we get a press and release event. Because it happens within the same frame it gets discarded, but this is not right. It's a bit hard to see with all the noise but afaict in E: 0.436065 when the second finger comes down, BTN_LEFT is released and stays released (because of the above events). So this is really not libinput's fault, you should be impressed it doesn't get angry at you for sending those events ;)

Not sure what's going on in the driver here, is this a custom one?
Comment 7 Carlo Caione 2018-01-22 10:47:32 UTC
> Not sure what's going on in the driver here, is this a custom one?

Not at all, it's the usual `hid_multitouch`.
Comment 8 Peter Hutterer 2018-01-22 11:03:05 UTC
attach a hid recording please, see https://bentiss.github.io/hid-replay-docs/
Comment 9 Carlo Caione 2018-01-22 11:14:47 UTC
Created attachment 136891 [details]
zyrex_hid_log

> attach a hid recording please
In attachment (I'll also post a second log in the next comment)

> On every hw event we get a press and release event. Because it happens within
> the same frame it gets discarded, but this is not right. It's a bit hard to
> see with all the noise but afaict in E: 0.436065 when the second finger comes
> down, BTN_LEFT is released and stays released (because of the above events).
I see that. What should be the correct behavior here? Not having the press / release event at all or the problem is that they happen within the same frame? (or something else entirely?)
Comment 10 Carlo Caione 2018-01-22 11:15:06 UTC
Created attachment 136892 [details]
zyrex_hid_log_2
Comment 11 Benjamin Tissoires 2018-01-22 12:44:16 UTC
Hans had the same issue a couple of month ago.

This should be now fixed by https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/drivers/hid/hid-multitouch.c?h=for-next&id=55746d28d66860bccaae20a67b55b9d5db7c14af

However, this is scheduled for v4.16, so not in Linus' tree yet :(
Comment 12 Carlo Caione 2018-01-22 13:18:37 UTC
(In reply to Benjamin Tissoires from comment #11)
> Hans had the same issue a couple of month ago.
> 
> This should be now fixed by
> https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/drivers/
> hid/hid-multitouch.c?h=for-next&id=55746d28d66860bccaae20a67b55b9d5db7c14af
> 
> However, this is scheduled for v4.16, so not in Linus' tree yet :(

Ok, this actually solves the issue.
Thank you very much for pointing this out!

Cheers,

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.