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

Peter Hutterer peter.hutterer at who-t.net
Wed Jun 3 22:28:15 PDT 2015


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 :)

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


More information about the wayland-devel mailing list