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!
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.
(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,
Definitely works here, but it *may* not work depending on your hardware (some missing features/older hardware/...). An evemu-record should confirm this.
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.
Created attachment 136890 [details] zyrex_clickpad_2_fingers_evemulog_2 Another recording (just in case).
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?
> Not sure what's going on in the driver here, is this a custom one? Not at all, it's the usual `hid_multitouch`.
attach a hid recording please, see https://bentiss.github.io/hid-replay-docs/
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?)
Created attachment 136892 [details] zyrex_hid_log_2
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 :(
(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.