[RFC PATCH v2 wayland] protocol: add wl_pointer.axis_source, axis_stop and axis_discrete events

[Jonas Ådahl]

On Tue, Apr 07, 2015 at 01:19:24PM +1000, Peter Hutterer wrote:
> On Fri, Mar 27, 2015 at 10:23:43AM +0800, Jonas Ådahl wrote:

<snip>

> > 
> > Follow up questions:
> > 
> > Do we expect to get axis_stop on both the horizontal and vertical axes,
> > and is the client supposed to trigger its kinetic scrolling when both
> > axises has stopped or just the first one? How would one interpret only
> > one axis receiving the stop event but not the other?
> 
> I'm not sure here tbh. I think it'd be good enough to say that this affects
> all scroll directions currently active, but that's based on a couple of
> conditions:
> * the case of kinetic scrolling on two devices independently is a niche case
>   we don't care about. that's easy

Yea that sounds a bit unusual. One touchpad for each hand, one for
horizontal and one for vertical movements? :P

> * we only have scroll axes so far, if we add unrelated axes to the
>   wl_pointer.axes set this gets a bit hairy. e.g. does a kinetic scrolling
>   stop affect a future rotation axis?
>   the solution here could be to add flags to the stop event to specify the
>   axes that stopped scrolling.

Given what you said above (axis_stop affecting all scroll directions),
it'd mean it'd have to be an array, since we otherwise would need two
axis_stop events to get an atomic end event. Or say "any axis_stop on
a "scroll" axis stops the other one as well.

> 
> > Will we ever send axis_stop when the source is 'continuous' (or any
> > other possibe source), and how to determine what source had its movement
> > stopped in that case? With the current version, "axis_stop" is rather
> > hard coded to "axis_finger_lifted" behind a generic name (which maybe is
> > not that bad anyway though).
> 
> I'll have to double check the code but iirc we send axis stop events in
> libinput for some continuous scrolling. e.g. trackstick middle button
> scrolling - releasing the middle button sends the scroll termination event.
> we don't have a pre-notification in libinput though, so you won't know until
> you get that stop event that you will get one. That's fixable but whether
> it's needed is another matter: if you get it you'll get it fast enough to
> trigger kinetics, otherwise you time out (and the stop event may come in
> after the timeout).

True, I suppose there is no usefulness with a warning.

> 
> the axis_source is still prefixed to the axis_stop event, but that doesn't
> scale if you have to independent scroll devices that use the same type.
> Again, a question of whether that's required, if so we could assign some
> sort of tracking ID to the scroll sequence like the touch sequences
> have.

Sounds a bit complex. If it ever turns out it is needed, that could be
made into a separate extension IMHO.

> 
> 
> > > > > +    </event>
> > > > > +
> > > > > +    <event name="axis_discrete" since="5">
> > > > > +      <description summary="axis click event">
> > > > > +        Scroll and other axis discrete step information.
> > > > > +
> > > > > +        This event does not occur on its own. It is sent before a
> > > > > +        wl_pointer.axis event and carries the axis value of the
> > > > > +        wl_pointer.axis event in discrete steps (e.g. mouse wheel clicks).
> > > > > +
> > > > > +        This event is optional, continuous scrolling devices
> > > > > +        like two-finger scrolling on touchpads do not have discrete
> > > > > +        steps.
> > > > 
> > > > Hmm. This means we wouldn't be able to convert the touch based scroll
> > > > motions into the old scroll step clicks, since we wouldn't (reliably)
> > > > know when a device would emit their own, since it doesn't specify
> > > > exactly when to expect and not to expect. The client won't know whether
> > > > there are "continuous scrolling devices" or not.
> > > > 
> > > > Wouldn't it be easier to just provide XI2 style smooth scroll vectors,
> > > > i.e. steps in "discrete scale", where a mouse scroll click is -1.0 or
> > > > 1.0 and continuous scrolling is a fraction of such. Clients implementing
> > > > version 5 can simply use the accumulation method for emitting scroll
> > > > clicks without having to rely on the old "divide by 10" hack.
> > > > 
> > > > This event is actually more like what I described in my previous mail
> > > > that were more or less concluded to be not worth it, isn't it?
> > > 
> > > the wl_pointer.axis documentation defines the axis events to be in the same
> > > coordinate space as motion data, there is nothing accommodating for mouse
> > > wheel clicks. it's just magic knowledge with the value 10.
> > > Adding this event set removes that magic knowledge, if you get an
> > > axis_discrete event you can safely ignore the axis value and just scroll by
> > > the discrete value. 
> > > 
> > > I don't think the two should be merged into the same coordinate space. It'd
> > > be easier but also more error-prone. For example, on a touchpad you probably
> > > want scrolling to move at the same speed as the cursor would otherwise so
> > > the content follows the finger (this is a lot more obvious when natural
> > > scrolling is enabled). But a click is a click and maps to say 3 lines, or a
> > > page, or whatever in the context. They are physically two different
> > > coordinate spaces, I don't think merging them will help.
> > > 
> > > So I think of this less as "add continuous sources" because that's what the
> > > protocol already is. I think of it as adding wheel click information for
> > > when a continuous space isn't right. Does that make sense or did I miss the
> > > point?
> > 
> > I didn't say we should merge the coordinate spaces, but rather make
> > axis_discrete value a wl_fixed_t value in discrete coordinate space. We
> > cannot change wl_pointer.axis and doing so would loose information which
> > is bad. The problem is that clients often still need to continue emulate
> > "clicks" for all type of scrolling methods including touch scroll, and
> > since the current proposal of wl_pointer.axis_discrete is only sent for
> > actual scroll clicks, that situation isn't improved at all. We still
> > need the magic / 10 in the clients, except now with an extra if (source
> > != wheel). We'd also not get rid of the XI2 smooth scroll scaling in
> > clients.
> > 
> > Or are you saying we should keep the scroll click and XI2 smooth scroll
> > emulation where they are now?
> 
> tbh, I'm not a big fan of sending things we don't have. if a client needs to
> convert a continuous space into discrete clicks, IMO it should do on its
> own terms. changing to a wl_fixed_t as data type is no problem, but sending
> discrete values for e.g. two-finger scrolling isn't ideal.

I think changing the data type is pretty pointless if it'd only ever
emit integer values. The only reason for making it wl_fixed_t would be
to have the compositor emulate discrete scroll events in the same way as
it is done in X today. Without it we still need to have clients do their
own emulation.


Jonas