Bug 1233844

Summary: trackpoint movement and touchpad scrolling doesn't work simultaneously
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: xorg-x11-drv-libinputAssignee: Peter Hutterer <peter.hutterer>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: hdegoede, kparal, peter.hutterer
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libinput-0.18.0-5.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-10 19:06:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
evemu-describe of the touchpad
none
core dump info none

Description Kamil Páral 2015-06-19 15:02:45 UTC 
Description of problem:
First, here's a description how I usually work:
Both hands on keyboard, left index finger on trackpoint to move the mouse cursor, right thumb on the right edge of touchpad to scroll up and down (edge scrolling). Mouse button presses are done using the hardware buttons above the touchpad area, left thumb for left click, right thumb for right click. This allows very fast and efficient control in a web browser without lifting your fingers from the keyboard at all.

This worked perfectly in past Fedora releases, including Fedora 21. I was able to _simultaneously_ control both the cursor position by trackpoint and scrolling by touchpad.

Once I upgraded to Fedora 22, while still using synaptics driver, simultaneous control stopped working. When I was moving the cursor using trackpoint, I was not able to scroll. Once I stopped the cursor, I was immediately able to scroll.

Then I installed xorg-x11-drv-libinput, and it got even worse. Not only that trackpoint and touchpad scrolling does not work simultaneously, but there's a forced delay between these two, about 1 second. So even if I stop moving the cursor by the trackpoint, I need to wait about 1 second before I can start scrolling using the touchpad. There is no delay the other way, the trackpoint always responds immediately. So the problem is only when using trackpoint and then wanting to immediately use the touchpad.

This behavior is quite annoying for me, because it goes against my reflexes. When reading web pages, all it takes is just a slight cursor movement, and scrolling stops working. When I try to scroll, I'm always confused why it is not working, then I realize the problem, and then I need to wait for what seems like eternity (1 second) until I can finally move the page again.

I'm not sure if this behavior is intentional or not, but I'd love to see it fixed, because:
a) it used to work before
b) when using mouse, you can also move the cursor and scroll at the same time (and you often do). Using trackpoint + touchpad scrolling is just another way of achieving the same using different hardware devices.
c) I see no reason why different input devices should be in exclusive mode, disabling all other connected devices every time they generate some events
d) there is no delay in the touchpad -> trackpoint direction, it seems inconsistent to force delay in the trackpoint -> touchpad direction.

Thank you for consideration.

I can append any logs needed, just tell me which.


Version-Release number of selected component (if applicable):
xorg-x11-drv-libinput-0.10.0-5.fc22.x86_64
xorg-x11-drv-synaptics-1.8.2-2.fc22.x86_64
xorg-x11-server-Xorg-1.17.1-14.fc22.x86_64
Thinkpad T500


How reproducible:
always

Steps to Reproduce:
1. open a long page in firefox
2. move the cursor using trackpoint
3. try to scroll on the touchpad using the right edge at the same moment - nothing happens
4. try again immediately after stopping the cursor - nothing happens, until 1 second passes and it starts to work
Comment 1 Peter Hutterer 2015-06-23 05:44:08 UTC 
This is a side effect of the palm detection, it's an intended feature. Using the trackpoint laptops with large touchpads causes accidental touches, so we disable the touchpad while the trackpoint is in use (and for 500ms afterwards). That also answers b, c, and d - the answer to a) is simply that the drivers didn't talk to each other, so this thing wasn't possible before.


There's another approach that I quickly tried here: reduce the timeout to 100ms but keep already existing touches inactive. So those that use the trackpoint and rest the palm on or near the touchpad get the touches ignored while a quick switch between the two devices is still possible.
Try this build here, how does this work for you?

http://koji.fedoraproject.org/koji/taskinfo?taskID=10188195
Comment 2 Kamil Páral 2015-06-23 18:34:31 UTC 
Unfortunately, it's not better. The reduced delay could make it feel snappier I guess, but it now has the following issue: If I start scrolling before the cursor is still, or when it is still but during the 100ms delay (I guess), the scroll movement is completely ignored, even after the delay passes (and I'm still scrolling - or rather trying to scroll).

So before, the delay was uncomfortable, but at least scrolling started working eventually (after 500ms). With the patched version, the scrolling doesn't start at all. I have to stop scrolling and start again, and then it finally works.

There is one further bug, if I start scrolling, then move the cursor with trackpoint (while still scrolling even though it doesn't do anything), and then stop moving the cursor using the trackpoint, the touchpad switches from 'scrolling mode' to 'movement mode' and my cursor starts moving vertically (instead of resuming scrolling up and down). But that's not directly related to this bug, just noting.


(In reply to Peter Hutterer from comment #1)
> This is a side effect of the palm detection, it's an intended feature. Using
> the trackpoint laptops with large touchpads causes accidental touches, so we
> disable the touchpad while the trackpoint is in use (and for 500ms
> afterwards).

Because I don't have a laptop with a large touchpad, and I don't need palm detection at all, is it be possible to configure and disable this somewhere just for me, locally? I don't want to claim that my way of working is widespread or "the only correct way", and I understand that the changes you described help a lot of people with different hardware than I have, but it would be great if this could be switched to the old, non-exclusive mode for those who have hardware not affected by those palm detection issues.
Comment 3 Peter Hutterer 2015-06-24 00:26:24 UTC 
Try this one then:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10194331

please attach an evemu-describe of your touchpad as well please, thanks.


(In reply to Kamil Páral from comment #2)
> There is one further bug, if I start scrolling, then move the cursor with
> trackpoint (while still scrolling even though it doesn't do anything), and
> then stop moving the cursor using the trackpoint, the touchpad switches from
> 'scrolling mode' to 'movement mode' and my cursor starts moving vertically
> (instead of resuming scrolling up and down). But that's not directly related
> to this bug, just noting.

unrelated, but should be fixed. though with the first patch this will become obsolete anyway, since the finger will be ignored until touch up now.
Comment 4 Peter Hutterer 2015-06-24 01:45:55 UTC 
try this one too please. the one in comment 3 should disable it on your touchpad if it's small enough, this one is enabled but with a slightly smarter approach

http://koji.fedoraproject.org/koji/taskinfo?taskID=10194505
Comment 5 Kamil Páral 2015-06-26 14:06:43 UTC 
Created attachment 1043526 [details]
evemu-describe of the touchpad
Comment 6 Kamil Páral 2015-06-26 14:08:45 UTC 
Created attachment 1043527 [details]
core dump info

(In reply to Peter Hutterer from comment #3)
> Try this one then:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=10194331

That one crashes for me when I want to log in or switch to a different VT (it always reloads the login screen and switches current VT, so I can't basically do nothing with that computer other than ssh in). Core dump info from coredumpctl attached.
Comment 7 Kamil Páral 2015-06-26 14:18:41 UTC 
(In reply to Peter Hutterer from comment #4)
> try this one too please. the one in comment 3 should disable it on your
> touchpad if it's small enough, this one is enabled but with a slightly
> smarter approach
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=10194505

I guess there is a slight difference, it feels a bit better, but I can't fully pinpoint it. Maybe I can now start scrolling during the timeout and it starts working once the timeout is over?

I still can't start scrolling before making the cursor still - if I do, there is no effect until I stop scrolling and start again.

But overall it is definitely better than current stable version of libinput (with the long timeout).

(In reply to Peter Hutterer from comment #3)
> unrelated, but should be fixed. though with the first patch this will become
> obsolete anyway, since the finger will be ignored until touch up now.

Doesn't seem fixed with libinput-0.18.0-1.3.bz1233844.fc22. I can still reproduce it exactly the same way as before.

By the way, I've found out that with libinput I can now hold the middle mouse button above touchpad and use trackpoint to scroll up and down, in any application. That is awesome, I love it. I might not need fixing the issue in question after all :) OTOH I assume some people would still appreciate the changes, so if you're willing to further work on this, I'll be happy to provide feedback.
Comment 8 Peter Hutterer 2015-06-28 22:54:37 UTC 
(In reply to Kamil Páral from comment #7)
> I guess there is a slight difference, it feels a bit better, but I can't
> fully pinpoint it. Maybe I can now start scrolling during the timeout and it
> starts working once the timeout is over?

yes, it looks at the timestamp of the touch. if it started after the last trackpoint event it will be released for scrolling after the (now shorter timeout). but a touch starting while the trackpoint is active will be ignored (i.e. resting the palm on the touchpad is permitted).
it's sort-of the middle-ground between the two approaches.

> I still can't start scrolling before making the cursor still - if I do,
> there is no effect until I stop scrolling and start again.

correct, that's intended behaviour.


> (In reply to Peter Hutterer from comment #3)
> > unrelated, but should be fixed. though with the first patch this will become
> > obsolete anyway, since the finger will be ignored until touch up now.
> 
> Doesn't seem fixed with libinput-0.18.0-1.3.bz1233844.fc22. I can still
> reproduce it exactly the same way as before.

yeah, it's not "fixed" in the way that it works completely simultaneously, but it is a slight improvement over the current behaviour. as you mentioned in an earlier comment you don't need palm detection and after testing this on a couple of touchpads here I agree - palm detection is only needed on larger touchpads. so the final result will be a combination of -2 and -3.

> By the way, I've found out that with libinput I can now hold the middle
> mouse button above touchpad and use trackpoint to scroll up and down, in any
> application. That is awesome, I love it. I might not need fixing the issue
> in question after all :) OTOH I assume some people would still appreciate
> the changes, so if you're willing to further work on this, I'll be happy to
> provide feedback.

middle button scrolling is _a lot_ more common than using both devices simultaneously (judging by bugreports at least :)
Comment 9 Fedora Update System 2015-06-30 23:57:43 UTC 
libinput-0.18.0-5.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.18.0-5.fc22
Comment 10 Fedora Update System 2015-07-02 17:07:46 UTC 
Package libinput-0.18.0-5.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libinput-0.18.0-5.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11016/libinput-0.18.0-5.fc22
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2015-07-10 19:06:13 UTC 
libinput-0.18.0-5.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.