Kinetic scrolling improperly interacts with modifier keys

[Alex Launi]

On natty with the multi-touch track pad on my macbook pro, when I do a fast scroll on a tab, and then hit ctrl+w while the kinetic scroll is still in progress, the system interprets this as ctrl+scroll and zooms into my page, and then closes the tab.
---
.proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 270.29 Wed Feb 23 16:18:35 PST 2011
 GCC version: gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-3ubuntu3)
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,scale,session,unityshell]
CompositorRunning: compiz
DistUpgraded: Yes, recently upgraded Log time: 2010-12-24 20:47:19.877044
DistroCodename: natty
DistroRelease: Ubuntu 11.04
DistroVariant: ubuntu
GraphicsCard:
 nVidia Corporation Device [10de:08a0] (rev a2) (prog-if 00 [VGA controller])
   Subsystem: Apple Computer Inc. Device [106b:00c2]
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
MachineType: Apple Inc. MacBookPro7,1
NonfreeKernelModules: nvidia wl
Package: xserver-xorg-input-evdev 1:2.6.0-1ubuntu8
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-5-generic root=UUID=c1f1bd83-c7aa-402f-9a4c-6c1ebc2f681c ro quiet splash reboot=pci vt.handoff=7
ProcVersionSignature: Ubuntu 2.6.38-5.32-generic 2.6.38-rc6
Renderer: Unknown
Tags: natty running-unity ubuntu compiz-0.9
Uname: Linux 2.6.38-5-generic x86_64
UpgradeStatus: Upgraded to natty on 2011-01-06 (56 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers
dmi.bios.date: 03/25/10
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP71.88Z.0039.B05.1003251322
dmi.board.name: Mac-F222BEC8
dmi.board.vendor: Apple Inc.
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-F222BEC8
dmi.modalias: dmi:bvnAppleInc.:bvrMBP71.88Z.0039.B05.1003251322:bd03/25/10:svnAppleInc.:pnMacBookPro7,1:pvr1.0:rvnAppleInc.:rnMac-F222BEC8:rvr:cvnAppleInc.:ct10:cvrMac-F222BEC8:
dmi.product.name: MacBookPro7,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.4-0ubuntu1
version.libdrm2: libdrm2 2.4.23-1ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1~git20110215.cc1636b6-0ubuntu2
version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A
version.xserver-xorg: xserver-xorg 1:7.6~3ubuntu8
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-1ubuntu11
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu5

[Anders Kaseorg (andersk)]

Now that scroll coasting is on by default, I’ve noticed that it has a funny interaction with modifier keys. If I flick and release my fingers to initiate coasting, then I press Ctrl afterwards while my document is still scrolling, it immediately starts zooming instead.

Probably the right solution is for any input activity (not just any touchpad activity) to halt the coasting operation in progress.

I’m using xserver-xorg-input-synaptics 1.3.99+git20110116.0e27ce3a-0ubuntu3 in Ubuntu natty.

[Peter Hutterer (peter-hutterer)]

not sure how to fix this actually. synaptics only generates mouse events, the keyboard events aren't visible to the driver so it cannot stop. Having a client-side daemon that does the job is racy since some events will be sent before the client gets a chance to deactivate the events.

and the server doesn't know about it at all, it simply forwards the events.

[Anders Kaseorg (andersk)]

Hmm. Well, how should this be handled? Perhaps the coasting functionality belongs in the server, or even in the toolkits, instead?

It occurs to me that the same problem might happen if the window being scrolled disappears in the middle of coasting, leaving further coasting events to be sent to the window behind it. Or similarly if another window appears on top of it. Theoretically, such events could happen without the user touching the touchpad or the keyboard, e.g. with programs that take a long time to open or close.

It’s probably worth talking about this with the server and toolkit developers, especially now that patches are floating around for high-resolution scrolling, which also needs server and toolkit changes:

http://<email address hidden>/msg13110.html

[Anders Kaseorg (andersk)]

> Having a client-side daemon that does the job is racy since some events will be
> sent before the client gets a chance to deactivate the events.

Thinking about this idea some more: What if the client-side daemon was actively sending fake scroll events to the window, rather than just passively waiting for the right moment to tell the driver to deactivate a stream of real events?

Then the only effect of losing the race would be that some extra scroll events get sent to the original window with the original modifier state, rather than to whatever window is now under the pointer with the current modifier state.

[Peter Hutterer (peter-hutterer)]

(In reply to comment #2)
> Hmm. Well, how should this be handled? Perhaps the coasting functionality
> belongs in the server, or even in the toolkits, instead?

not quite that easy, but maybe one day when we have multitouch events proper.

(In reply to comment #3)
> > Having a client-side daemon that does the job is racy since some events will be
> > sent before the client gets a chance to deactivate the events.
>
> Thinking about this idea some more: What if the client-side daemon was actively
> sending fake scroll events to the window, rather than just passively waiting
> for the right moment to tell the driver to deactivate a stream of real events?
>
> Then the only effect of losing the race would be that some extra scroll events
> get sent to the original window with the original modifier state, rather than
> to whatever window is now under the pointer with the current modifier state.

the grab model in both the core protocol and the XI extension pretty much prevent this from happening in a sensible manner. similar things have been proposed in the past but we're pretty much cornered by the protocol here.

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Alex Launi (alexlauni)]

apport information

[Duncan McGreggor (oubiwann)]

Chase, I had Alex file this against the synaptics driver for apport-collect... We aren't really sure where the problem is. Once you dig in and find it, we'll leave it to you to file against the right package and project :-)

Thanks!

[Chase Douglas (chasedouglas)]

Due to the way scroll events are handled in X today, there's no way around this. The scroll events are generated in the X input module, which has no idea of what is really going on on the desktop. One could say that your application should see the closure of a tab and then ignore all scroll events until scrolling stops, but scroll events are handled as button presses so the X client doesn't know when scrolling has stopped. This issue can also be found in OS X where you can do similar things.

The goal is to replace X input module scroll events with utouch gesture events. These events can know about the window hierarchy so they terminate when a window is closed. The gestures also have a start and a stop, allowing the utouch client to stop handling a scroll gesture when the tab has closed until the gesture ends.

Because there's no real resolution to this issue in the current toolkits/X, I'm closing this as Won't Fix.

[Duncan McGreggor (oubiwann)]

Before we leave this bug behind, I'd like to formulate a plan of action.

Chase, you said the following:

"The goal is to replace X input module scroll events with utouch gesture events. These events can know about the window hierarchy so they terminate when a window is closed. The gestures also have a start and a stop, allowing the utouch client to stop handling a scroll gesture when the tab has closed until the gesture ends."

In brief, how will this be accomplished?

With your above paragraph and the answer to my question, I'll start a blueprint for discussion/planning at UDS.

[Chase Douglas (chasedouglas)]

Essentially, it will require the toolkits using our utouch stack for gestures. We should integrate geis into a toolkit and have two finger pans be used for scrolling. However, further details requires people with insight into toolkit internals, which I don't have right now...

[Alex Launi (alexlauni)]

Chase the real problem is that it keeps firing the events after the scroll has terminated. I can have my fingers off of the touchpad for (what I interpret to be) close to a half second, and I'll still get bit by zoom if I hit ctrl.

[Chase Douglas (chasedouglas)]

That's the definition of "kinetic" scrolling. The scroll has "momentum" that persists after you stop the scrolling motion. You can hit the issues outlined in the previous comments whenever you have kinetic scrolling on. What should be happening is the toolkits should be performing the momentum calculations, not the x input module. The input module doesn't know what the state of the cursor, keyboard, or windows on screen are. However, configuration across toolkits will be needed before this can be fully realized.

If you want to disable kinetic scrolling for now, do the following:

$ xinput list
Find the id for your trackpad
$ xinput set-prop <device id> "Synaptics Coasting Speed" 0 0

This disables both vertical and horizontal kinetic scrolling.

[pablomme (pablomme)]

One can also trigger kinetic scrolling, move the pointer and have the mousewheel clicks land in an undesired location, e.g., by scrolling in chromium and immediately moving the pointer to the tab area.

Surely the synaptics driver is in a position to be able to stop kinetic scrolling when the pointer is moved (at all, or beyond a threshold). I can't think of a situation where the current behaviour is desirable. Similarly (although I believe this would involve two separate drivers talking to each other, so I'm unsure about how easy this would be), the synaptics driver should stop sending these delayed events if the status of any keyboard modifier changes, which would address the bug reported here.

[Chase Douglas (chasedouglas)]

Hi pablomme,

I believe we can distill your thoughts down to two issues:

1. Stopping scrolling when synaptics moves the pointer
2. Stopping scrolling when any other input module moves the pointer or presses a key

The first is simple and is implemented as far as I can tell. If I scroll fast with momentum and then touch again to drag the mouse, the scrolling stops.

The second is much trickier and would be very difficult to implement without creating some sort of protocol and mechanism for input modules to talk to each other or for an input module to query the state of another input device. If you have thoughts on this, I would suggest commenting on the upstream bug at x.org, which is linked to at the top of this bug report.

[shanen (Shannon Jacobs) (shanen)]

I think this bug is affecting me because I cannot install ANY keyboard for my ThinkPad--but at this point I'm expecting Ubuntu to become more useless and troublesome with each so-called upgrade. Look, I'm just trying to do the upgrade, and the first question it asks is for a keyboard, but it does NOT offer ANY option that is recognizably similar to the keyboard they I am using. I wouldn't mind so much if it was some kind of exotic computer, but it is NOT. Just a plain Jane Lenovo X61 ThinkPad. Ever heard of it? Evidently not.

Look, I really want you to succeed (at despicable Microsoft's cost), but you are failing more and more. I have already decided NOT to install Ubuntu on any more machines, because it gets worse and worse each time. At this point I'm still attempting to update some of my VMware installations... Or at least I tried it once. The evidence so far is that I should just give up now and save myself the additional grief.

I'm sure this is a waste of time, but I'm going to repeat myself: I don't blame you for failing. I think the deep problem is your economic model, which is basically the big donor model for charity. That can work if the donor is rich enough, but he isn't, or if he always makes perfect decisions, but he doesn't. I'm going to try to end on a constructive note that addresses the REAL problem here by suggesting that you need to adjust your economic model to get MUCH more testing into the process. My main conclusion at this point is that you need to insure there is enough testing BEFORE you release ANY upgrade, even if it delays the upgrades. Here's a suggested funding mechanism that would get committed funds from small donors (who would also be potential testers) BEFORE you even start the actual programming:

http://eco-epistemology.blogspot.com/2009/11/economics-of-small-donors-reverse.html

[Peter Hutterer (peter-hutterer)]

*** This bug has been marked as a duplicate of bug 38909 ***