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.
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.
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://www.mail-archive.com/gtk-devel-list@gnome.org/msg13110.html
> 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.
(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.
*** This bug has been marked as a duplicate of bug 38909 ***
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.