Launchpad has imported 6 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=33856.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-02-03T03:13:04+00:00 Anders Kaseorg wrote: 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. Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/0 ------------------------------------------------------------------------ On 2011-02-08T01:42:05+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/1 ------------------------------------------------------------------------ On 2011-02-08T04:46:34+00:00 Anders Kaseorg wrote: 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 Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/2 ------------------------------------------------------------------------ On 2011-02-08T05:08:33+00:00 Anders Kaseorg wrote: > 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. Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/3 ------------------------------------------------------------------------ On 2011-02-09T02:29:28+00:00 Peter Hutterer wrote: (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. Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/4 ------------------------------------------------------------------------ On 2012-03-14T01:49:07+00:00 Peter Hutterer wrote: *** This bug has been marked as a duplicate of bug 38909 *** Reply at: https://bugs.launchpad.net/utouch/+bug/728643/comments/43 ** Changed in: xorg-driver-synaptics Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-input-synaptics in Ubuntu. https://bugs.launchpad.net/bugs/728643 Title: Kinetic scrolling improperly interacts with modifier keys To manage notifications about this bug go to: https://bugs.launchpad.net/utouch/+bug/728643/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
