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

[Jonas Ådahl]

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?


Jonas

> 
> > > ---
> > > This is on top of the other patch, I kept it separate for simpler review.
> > > 
> > > Cheers,
> > >    Peter
> > > 
> > >  protocol/wayland.xml | 24 ++++++++++++++++++++++++
> > >  1 file changed, 24 insertions(+)
> > > 
> > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > > index db6753a..aad238b 100644
> > > --- a/protocol/wayland.xml
> > > +++ b/protocol/wayland.xml
> > > @@ -1573,6 +1573,30 @@
> > >      </request>
> > >  
> > >      <!-- Version 5 additions -->
> > > +    <event name="axis_frame" since="5">
> > > +      <description summary="end of axis set event">
> > > +	Indicates the end of a set of wl_pointer.axis events that logically
> > 
> > Tab vs space compared to the rest :P
> 
> aargh. ok, stray vimdir entry is now removed.
> 
> Cheers,
>    Peter
> 
> > 
> > 
> > Jonas
> > 
> > 
> > > +        belong together.
> > > +
> > > +        All wl_pointer.axis events or wl_pointer.axis_stop events sent
> > > +        before a wl_pointer.axis_frame event belong logically together. For
> > > +        example, in a diagonal scroll motion the compositor will send two
> > > +        wl_pointer.axis events (horizontal and vertical) followed by a
> > > +        wl_pointer.axis_frame event. The client may use this information to
> > > +        calculate a diagonal vector for scrolling.
> > > +
> > > +        When multiple wl_pointer.axis events occur within the same frame,
> > > +        the motion vector is the combined motion of all events.
> > > +        When a wl_pointer.axis and a wl_pointer.axis_stop event occur within
> > > +        the same frame, this indicates that axis movement in one axis has
> > > +        stopped but continues in the other axis.
> > > +        When multiple wl_pointer.axis_stop events occur within in the same
> > > +        frame, this indicates that these axes stopped in the same instance.
> > > +
> > > +        wl_pointer.axis_frame may logically group events from multiple
> > > +        different wl_pointer.axis_sources.
> > > +      </description>
> > > +    </event>
> > >  
> > >      <enum name="axis_source">
> > >        <description summary="axis source types">
> > > -- 
> > > 2.4.1
> > >