Bug 38909

http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=56655fd15f676fea143f3963e23b464b275b2e77

and

http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=59151a548dcbac6f68e4f921b5c47aea4e5bc2a3

I suspect.

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

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.

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

Option "CoastingSpeed" "float"
Option "CoastingFriction" "float"


try adjusting them.

(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

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.

(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

(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.

(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)]

Created attachment 51993 [details]
Xorg.0.log

Created attachment 51994 [details]
Evtest

Scrolling slowly
waiting ~ 1 second
scrolling faster
waiting ~ 1 second
scrolling even faster
waiting ~ 1 second

(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.

(I'm trying to change the parameters you suggested, but I'll report later)

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.

(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.

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

(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.

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...

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.

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).

(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.

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 ?)

(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

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.

*** Bug 33856 has been marked as a duplicate of this bug. ***

*** Bug 58240 has been marked as a duplicate of this bug. ***

*** Bug 76094 has been marked as a duplicate of this bug. ***

Thanks for triaging this.

Couldn't this be turned into an enhancement request in xorg somewhere?

Thanks for triaging this.

Couldn't this be turned into an enhancement request in xorg somewhere?

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.

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.

(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.

*** Bug 76094 has been marked as a duplicate of this bug. ***