Comment 42 for bug 728643

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