Bug 38909 - Scrolling events arrive even after scrolling ended
Summary: Scrolling events arrive even after scrolling ended
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: 7.6 (2010.12)
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard: 2011BRB_Reviewed
Keywords:
: 33856 58240 76094 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-02 07:40 UTC by Pietro Battiston
Modified: 2015-09-01 15:58 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (44.23 KB, text/x-log)
2011-10-05 00:53 UTC, Pietro Battiston
no flags Details
Evtest (27.62 KB, text/x-log)
2011-10-05 00:54 UTC, Pietro Battiston
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pietro Battiston 2011-07-02 07:40:33 UTC
Since some time (let's say a couple of months), the effect of scrolling lasts much more than the action of scrolling itself. I'm sure this didn't happen before.

One pathologic case in which it is evident is the following: with evince, open
a pdf, scroll up with a long movement of the finger (you're already on top) and immediately _after_ press the "ctrl" key (nothing should happen). The document will zoom out. Though you never actually pressed Ctrl+scrolling. The thing is very annoying, and it even happens across apps (start scrolling on some window, then switch to another: it still scrolls).

I would have bet that this was a problem of metacity slowly processing events,
but the same happens under twm, so it must be the driver. The version is 1.4.1, (1.4.1-1 Debian package).
For reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632223

Pietro
Comment 2 Pietro Battiston 2011-09-29 00:38:28 UTC
Using xserver-xorg-core 1.11.1 (Debian package 2:1.11.1-1), the bug is still present.

Also, it is present on my other computer too: it is an Acer Aspire 9500, also with a Synaptics TouchPad.

Instead, I'm unable to reproduce when using an external USB trackball.

Pietro
Comment 3 Peter Hutterer 2011-09-29 17:11:02 UTC
This isn't a bug, it's a feature. Please read the commit logs I pointed to.

If there is an issue with this feature and it is truly buggy, I need more details. But from what I can tell, it's working as expected right now.
Comment 4 Pietro Battiston 2011-09-30 03:50:17 UTC
I see. Sorry I didn't understand it before, I sincerely would have never suspected this could be considered a "feature". So I'll try to explain my issue with this feature.

I'm browsing a long pdf document. I scroll down vigorously. The document arrives to the bottom and I still don't find what I'm looking for at a glance, so I type "Ctrl+F". In the precise moment in which I press down "Ctrl", the document stops scrolling and starts zooming out.

Worse still (that's the main annoyance from my point of view): I'm browsing a long Firefox tab. I scroll down vigorously. Then, I press "Ctrl+PgDown" to switch to the adjacent tab. In the precise moment in which I press down "Ctrl" (or, better, in the following moments), the page I'm viewing has decreased in zoom until it became barely visible.
Since Firefox remembers my zoom level, next time I visit that page it will be also zoomed out too. This happened so many times that for some pages I visit frequently I don't even remember which was the correct size, so I adjust to some reasonable one until I notice that all pictures are scaled badly.

But you can imagine other combinations: you're on Inkscape, you scroll, but then press Alt+Tab to switch to evince: in the moment in which you press "Alt", Inkscape starts scrolling horizontally, then when you switch to evince it keeps on scrolling, and when you finally press "Ctrl+F" it zooms out. All with a single scroll action.

Those three "case studies" are not fantasy, but daily life for me.

The only "solution" is that I scroll, I wait 3-4 seconds, then I press Ctrl or whatever.

To be honest, maybe the idea is good at the driver level but the window manager should react differently, identifying a scrolling action as ended when a modifier is pressed/the window changes.... I have no idea. But as it is, it is unbearable.

Pietro
Comment 5 Peter Hutterer 2011-10-04 21:39:53 UTC
Option "CoastingSpeed" "float"
Option "CoastingFriction" "float"


try adjusting them.
Comment 6 Pietro Battiston 2011-10-04 23:17:48 UTC
(In reply to comment #5)
> Option "CoastingSpeed" "float"
> Option "CoastingFriction" "float"
> 
> 
> try adjusting them.

What do you mean? Should I create an "xorg.conf"?

(also, just out of curiosity, are you asking me to do some testing or just saying that the problem won't be fixed and suggesting a workaround?)

thanks for the info
Comment 7 Peter Hutterer 2011-10-04 23:32:35 UTC
yeah, sorry. wasn't clear enough. set up a xorg.conf.d snippet for these values. it looks to me that you're not happy with the defaults, which is fair enough. You can configure them.

there are a few other things that aren't much in our control though. e.g. Firefox renders quite slowly, so scroll events appear to last longer than they actually do in the driver.
Comment 8 Pietro Battiston 2011-10-04 23:54:22 UTC
(In reply to comment #7)
> yeah, sorry. wasn't clear enough. set up a xorg.conf.d snippet for these
> values. it looks to me that you're not happy with the defaults, which is fair
> enough. You can configure them.

I can restore the old, perfectly working behaviour only if I have admin powers?

Do you intend to port this "feature" to all touchpad/mouse drivers?


> 
> there are a few other things that aren't much in our control though. e.g.
> Firefox renders quite slowly, so scroll events appear to last longer than they
> actually do in the driver.


Yes, that certainly makes the issue worse (and that's clearly not just Firefox, in my experience that's any existing app).
Those defaults are a bit insane, really. I think I wouldn't have bothered for a couple of tens of seconds, but evince takes my scrolling as zooming out even if I press "Ctrl" after approx. 1 second. I saw this happen to friends that are certainly not top speed typers.

Also, again for curiosity, does it happen under Mac/Windows/any other desktop system that if I switch to a new window _after scrolling ended_, it still scrolls?! And whose fault is it? Metacity is slow? Or do events not processed by the slow original window rightly pile up?

Anyway, thanks for the hint, for the moment

Pietro
Comment 9 Peter Hutterer 2011-10-05 00:09:34 UTC
(In reply to comment #8)
> I can restore the old, perfectly working behaviour only if I have admin powers?

xinput set-prop "device name" "property name" value, or
synclient option=value

> Do you intend to port this "feature" to all touchpad/mouse drivers?

there's only one touchpad driver these days.
 
> Also, again for curiosity, does it happen under Mac/Windows/any other desktop
> system that if I switch to a new window _after scrolling ended_, it still
> scrolls?! 

yes. OS X does for example. try flicking your fingers on the touchpad and you'll notice that it keeps scrolling for a while.

> And whose fault is it? Metacity is slow? Or do events not processed
> by the slow original window rightly pile up?

how fast are you scrolling, are scrolling events generated for too long and if so for how long exactly, have you actually tried any of the options I suggested, what type of touchpad is this, can I have some evtest and xorg.log, etc.
Comment 10 Pietro Battiston 2011-10-05 00:42:53 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I can restore the old, perfectly working behaviour only if I have admin powers?
> 
> xinput set-prop "device name" "property name" value, or
> synclient option=value


great, thanks

> 
> > Do you intend to port this "feature" to all touchpad/mouse drivers?
> 
> there's only one touchpad driver these days.
> 
> > Also, again for curiosity, does it happen under Mac/Windows/any other desktop
> > system that if I switch to a new window _after scrolling ended_, it still
> > scrolls?! 
> 
> yes. OS X does for example. try flicking your fingers on the touchpad and
> you'll notice that it keeps scrolling for a while.
> 

I know OS X keeps scrolling. I explicitly asked about switching to a new window - what seems to me most absurd in the current behaviour.
Though I'm totally ignorant in the technicalities, I was trying to understand if the difference between what I'm experiencing and what happens in other OSes really lies in the driver, or possibly in the window managers. Anyway, never mind.


> > And whose fault is it? Metacity is slow? Or do events not processed
> > by the slow original window rightly pile up?
> 
> how fast are you scrolling, are scrolling events generated for too long and if
> so for how long exactly, have you actually tried any of the options I
> suggested, what type of touchpad is this, can I have some evtest and xorg.log,
> etc.

Now _that_'s a reply to a bug report.

I (usually) scroll approx. 1/2 to 3/4 of the touchpad height with a fast (I would extimate ~2/10 of second) move.
With the default values, in the simplest test case I can figure out, that is, scrolling down an evince document which is already at the bottom, "Ctrl" triggers zoom until approx. 1 second - 1 second and a half after the end of the.
I don't know what's exactly the "type of touchpad" (and I reproduced this on 3 different machines), but on my current machine "xinput --list" says

⎜   ↳ SynPS/2 Synaptics TouchPad              	id=11	[slave  pointer  (2)]
Comment 11 Pietro Battiston 2011-10-05 00:53:16 UTC
Created attachment 51993 [details]
Xorg.0.log
Comment 12 Pietro Battiston 2011-10-05 00:54:07 UTC
Created attachment 51994 [details]
Evtest

Scrolling slowly
waiting ~ 1 second
scrolling faster
waiting ~ 1 second
scrolling even faster
waiting ~ 1 second
Comment 13 Pietro Battiston 2011-10-05 00:54:25 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > I can restore the old, perfectly working behaviour only if I have admin powers?
> 
> xinput set-prop "device name" "property name" value, or
> synclient option=value


great, thanks

> 
> > Do you intend to port this "feature" to all touchpad/mouse drivers?
> 
> there's only one touchpad driver these days.
> 
> > Also, again for curiosity, does it happen under Mac/Windows/any other desktop
> > system that if I switch to a new window _after scrolling ended_, it still
> > scrolls?! 
> 
> yes. OS X does for example. try flicking your fingers on the touchpad and
> you'll notice that it keeps scrolling for a while.
> 

I know OS X keeps scrolling. I explicitly asked about switching to a new window - what seems to me most absurd in the current behaviour.
Though I'm totally ignorant in the technicalities, I was trying to understand if the difference between what I'm experiencing and what happens in other OSes really lies in the driver, or possibly in the window managers. Anyway, never mind, you certainly understand better than me.


> > And whose fault is it? Metacity is slow? Or do events not processed
> > by the slow original window rightly pile up?
> 
> how fast are you scrolling, are scrolling events generated for too long and if
> so for how long exactly, have you actually tried any of the options I
> suggested, what type of touchpad is this, can I have some evtest and xorg.log,
> etc.

Now _that_'s a reply to a bug report.

I (usually) scroll approx. 1/2 to 3/4 of the touchpad height with a fast (I would extimate 1/10 - 2/10 of second) move.
With the default values, in the simplest test case I can figure out, that is, scrolling down an evince document which is already at the bottom, "Ctrl" triggers zoom until approx. 1 second - 1 second and a half after the end of the end of the scrolling movement.
I don't know what's exactly the "type of touchpad" (and I reproduced this on 3 different machines, so they may have different types), but on my current machine "xinput --list" says

⎜   ↳ SynPS/2 Synaptics TouchPad              	id=11	[slave  pointer  (2)]


I attached
- xorg.0.log
- the output of evtest, when doing a slow, then a fast and then a very fast scrolling in sequence (waiting approx. 1 second in the intervals)

I'm available for any additional testing.
Comment 14 Pietro Battiston 2011-10-05 00:55:28 UTC
(I'm trying to change the parameters you suggested, but I'll report later)
Comment 15 Pietro Battiston 2011-10-30 13:23:24 UTC
OK, sorry for the delay, I experimented a bit.

Decreasing "CoastingSpeed" (i.e. to 5) limits the damage, but doesn't seem to solve the problem.

Increasing "CoastingFriction" does a better job, since it reduces the amount of time in which the scrolling will continue. With a value of 200, problems are much more rare. It still find occasionally some Firefox pages involuntarily zoomed out, when I scroll them then Ctrl+PgUp to another tab, but not crazy levels.

So resuming: 5 and 200-300 are optimal parameters, but the mechanism is simply buggy, though I don't know at which level. Scrolling "memory" should stop flowing when another key is pressed.
Comment 16 Peter Hutterer 2011-10-30 15:41:24 UTC
(In reply to comment #15)
> So resuming: 5 and 200-300 are optimal parameters, but the mechanism is simply
> buggy, though I don't know at which level.

smooth scrolling support in the upcoming 1.12 server can fix this issue if clients choose to do so.
Comment 17 Pietro Battiston 2011-10-31 09:10:24 UTC
Peter, I don't want to waste your time, but I really can't follow you, could you clarify a bit?

- How will clients be able to fix this issue (in the end, I already can, by setting an insanely high friction with the commands you suggested me)?

- Do you have any hint that overall users satisfaction was improved by this feature?

- Do you exclude that some other softwares (i.e. the window managers, or the graphic libraries) could solve my problem "in the right way", i.e. that Mac OSX/Android (though as far as I know in the latter a keyboard may be considered a rarity) do solve it at a higher level?

thanks
Comment 18 Peter Hutterer 2011-10-31 14:50:40 UTC
(In reply to comment #17)
> - How will clients be able to fix this issue (in the end, I already can, by
> setting an insanely high friction with the commands you suggested me)?

note that client == application, not user.
smooth scrolling means a client gets one (or few) events with high valuator values instead of a series of button events that keep going after the scrolling has stopped. Any physics engine is then handled by the client and won't suffer the same effects.

> - Do you have any hint that overall users satisfaction was improved by this
> feature?

I use it, the person who wrote it presumably wanted it. So there's two confirmed users that like it. Feel free to commission a proper study though.

> - Do you exclude that some other softwares (i.e. the window managers, or the
> graphic libraries) could solve my problem "in the right way", i.e. that Mac
> OSX/Android (though as far as I know in the latter a keyboard may be considered
> a rarity) do solve it at a higher level?

see smooth scrolling above.
Comment 19 Jeremy Huddleston Sequoia 2011-10-31 17:00:25 UTC
Maybe the modifier mask associated with the momentum scrolling should be based 
on the mask when the device event ended (ie when the fingers were removed from 
the pad) and not what its state is when the delayed event is enqueued...
Comment 20 Pietro Battiston 2011-10-31 18:07:45 UTC
To the best of my understanding (a.k.a. please ignore me if I misunderstood), that wouldn't solve the issue, which comes out when I press the modifier _after_ the finger was removed from the pad.
Comment 21 Jeremy Huddleston Sequoia 2011-10-31 20:30:32 UTC
Why don't you think that will solve the problem?  Perhaps an example:

1) You swipe scroll
2) You remove you finger from the trackpad
3) You press control

The momentum scroll events generated after you removed your finger should have a modifier mask without control set (ie the same modifier mask that existed when you removed your fingers).
Comment 22 Peter Hutterer 2011-10-31 21:24:47 UTC
(In reply to comment #21)
> Why don't you think that will solve the problem?  Perhaps an example:
> 
> 1) You swipe scroll
> 2) You remove you finger from the trackpad
> 3) You press control
> 
> The momentum scroll events generated after you removed your finger should have
> a modifier mask without control set (ie the same modifier mask that existed
> when you removed your fingers).

the driver doesn't have the modifier mask and the server doesn't know that the scrolling events are caused by emulation, not real events. it's one of the many many problems with having gestures in the drivers.
Comment 23 Pietro Battiston 2011-11-03 15:08:36 UTC
Just for future reference: under OS X (Lion), the problem is present within (some?) applications (i.e. OpenOffice will zoom if you press "cmd" just after scrolling), but not _between_ applications (no application will scroll if you start scrolling and then quickly switch to it).

Thanks Peter, can't wait to have smooth scrolling.

(which means something similar to the proposal in
http://old.nabble.com/Smooth-scrolling-td28068886.html ?)
Comment 24 Peter Hutterer 2011-11-28 21:42:58 UTC
(In reply to comment #23)
> Just for future reference: under OS X (Lion), the problem is present within
> (some?) applications (i.e. OpenOffice will zoom if you press "cmd" just after
> scrolling), but not _between_ applications (no application will scroll if you
> start scrolling and then quickly switch to it).

rough guess here is that the gesture, once initiated, keeps going to the same application until exhausted. which would be the same for proper multitouch support in X but not if the gesture is in the driver.

> 
> Thanks Peter, can't wait to have smooth scrolling.
> 
> (which means something similar to the proposal in
> http://old.nabble.com/Smooth-scrolling-td28068886.html ?)

yeah, similar: 
http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html
Comment 25 Peter Hutterer 2012-03-13 18:43:41 UTC
No clear resolution for this:

WONTFIX: we cannot fix this in the driver. we send old-style scroll events and expect clients to handle the scroll events accordingly. The driver has no knowledge of when you alt-tab, the server has no knowledge that scrolling is emulated in the driver with friction, and it's all just a cardhouse anyway.

RESOLVED: smooth scrolling with in-driver gestures disabled (notably friction) will resolve the issues as any inertia is now handled in the client. GTK already has implementations for this.

Given that smooth scrolling is the way into the future, I'm closing this as resolved, this cannot be fixed for old-style scrolling events other than by disabling in-driver friction.
Comment 26 Peter Hutterer 2012-03-13 18:49:07 UTC
*** Bug 33856 has been marked as a duplicate of this bug. ***
Comment 27 Peter Hutterer 2012-12-13 22:36:02 UTC
*** Bug 58240 has been marked as a duplicate of this bug. ***
Comment 28 Peter Hutterer 2014-03-12 23:45:37 UTC
*** Bug 76094 has been marked as a duplicate of this bug. ***
Comment 29 John Schmitt 2014-03-13 01:03:29 UTC
Thanks for triaging this.

Couldn't this be turned into an enhancement request in xorg somewhere?
Comment 30 John Schmitt 2014-03-13 01:03:39 UTC
Thanks for triaging this.

Couldn't this be turned into an enhancement request in xorg somewhere?
Comment 31 Peter Hutterer 2014-03-13 01:39:18 UTC
Enhancement requests have a tendency to just sit there and get ignored. With the current driver model this is hard and nasty to implement and your best bet is to turn coasting off in the driver and leave it to clients to handle smooth scrolling.
Comment 32 John Schmitt 2014-03-15 20:02:47 UTC
My feeling is that an enhancement request should be filed anyway.  When next someone takes up any refactoring or development effort, this might be put in the requirements.  You can see that there are at least a few people affected by this.
Comment 33 Anders Kaseorg 2014-06-14 22:09:49 UTC
(In reply to comment #25)
> RESOLVED: smooth scrolling with in-driver gestures disabled (notably
> friction) will resolve the issues as any inertia is now handled in the
> client. GTK already has implementations for this.

I don’t know if this is quite on-topic here anymore, but it’s just too amazing to avoid pointing out:

Now that we live in the future and Evince has smooth pixel scrolling with client-side inertia, it *still has the same bug*.

Wat.
Comment 34 Peter Hutterer 2014-08-03 21:17:47 UTC
*** Bug 76094 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.