[RFC PATCH wayland] protocol: add wl_pointer.axis_frame events

[Peter Hutterer]

On Thu, Jun 04, 2015 at 01:49:26PM +0800, Jonas Ådahl wrote:
> On Thu, Jun 04, 2015 at 03:28:15PM +1000, Peter Hutterer wrote:
> > On Thu, Jun 04, 2015 at 01:09:06PM +0800, Jonas Ådahl wrote:
> > > On Thu, Jun 04, 2015 at 02:41:52PM +1000, Peter Hutterer wrote:
> > > > To group separate vertical/horizontal scroll events together. Likewise it
> > > > enables axis_stop events to be grouped so that the final vector for kinetic
> > > > scrolling may be calculated correctly.
> > > > 
> > > > Multiple scroll sources within the same frame is not expected, but the
> > > > protocol allows this use-case, i.e. axis_frame events are not deliniators for
> > > > axis_source switches.
> > > 
> > > What is the intended use case for mixing sources within the same
> > > sequence? How would it ever be possible to trigger, given that different
> > > sources will, by the fact that they come from different places, never
> > > come at the same time? If we disallow it, we can make the semantics
> > > slighty simpler by saying that wl_pointer.axis_frame is always the
> > > "committing" event for all axis state, instead of the current proposal
> > > which is "axis_stop and axis, or just axis" depending on what event.
> > > 
> > > It is also a bit unclear how much sense it makes to have interpret a
> > > motion vector that contains both mouse wheel scroll distance and the
> > > touchpad scroll distance. They don't really logically belong together in
> > > any way I can think of.
> > 
> > not with the current sources, but the future case I mentioned in the other
> > email of thumb vs finger could trigger this. I'm not exactly sure _how_ yet
> > though, mainly since we don't have touchpads that could reliably detect
> > thumbs, at least not widespread enough.
> > 
> > That said even then it's arguably better to separate them by frames so I'm
> > not going to fight this too hard. Having a single source per frame would
> > simplify things and cut the number of events down, though realistically
> > probably not by as much as the frame adds in the first place :)
> 
> Not sure how I should interpret finger and thumb scroll "grouped
> logically" either. Also since the as well come at different places
> (anatomically) and thus different point in times (as long as I don't move
> my thumb and finger during the same millisecond, whey will always come
> separately anyway. Or would a thumb AND finger have both sources, but
> emit separate events that originated from some algorithm using both as
> input?

yeah, this is mostly where my fantasy starts giving in too, I honestly don't
know how to trigger this with the technology we have atm. Maybe a
finger+thumb pinch gesture?

then again, if we strain to find a current use-case it's better to
ignore this for now and add to the protocol later when we need to.

Cheers,
   Peter