[PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

[Jonas Ådahl]

On Wed, Nov 11, 2015 at 12:32:24AM +0100, Carlos Garnacho wrote:
> Hey,
> 
> On Tue, Nov 10, 2015 at 10:47 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Fri, Nov 06, 2015 at 09:26:47AM +0800, Jonas Ådahl wrote:
> >> On Thu, Nov 05, 2015 at 12:21:29PM -0600, Derek Foreman wrote:
> >> > On 04/11/15 07:24 PM, Jonas Ådahl wrote:
> >> > > On Thu, Nov 05, 2015 at 08:44:57AM +1000, Peter Hutterer wrote:
> >> > >> On Wed, Nov 04, 2015 at 09:57:35AM +0800, Jonas Ådahl wrote:
> >> > >>> On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote:
> >> > >> [...]
> >> > >>>> +    <event name="frame" since="5">
> >> > >>>> +      <description summary="end of a pointer event sequence">
> >> > >>>> +      Indicates the end of a set of events that logically belong together.
> >> > >>>> +      A client is expected to accumulate the data in all events events
> >> > >>>> +      within the frame before proceeding.
> >> > >>>> +
> >> > >>>> +      All wl_pointer events before a wl_pointer.frame event belong
> >> > >>>> +      logically together. For example, in a diagonal scroll motion the
> >> > >>>> +      compositor will send an optional wl_pointer.axis_source event, two
> >> > >>>> +      wl_pointer.axis events (horizontal and vertical) and finally a
> >> > >>>> +      wl_pointer.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.
> >> > >>>> +
> >> > >>>> +      A wl_pointer.frame event is sent for every logical event group,
> >> > >>>> +      even if the group only contains a single wl_pointer event.
> >> > >>>> +      Specifically, a client may get a sequence: motion, frame, button,
> >> > >>>> +      frame, axis, frame, axis_stop, frame.
> >> > >>>> +
> >> > >>>> +      The wl_pointer.enter and wl_pointer.leave events are logical events
> >> > >>>> +      generated by the compositor and not the hardware. These events are
> >> > >>>> +      also grouped by a wl_pointer.frame.
> >> > >>>
> >> > >>> I like the idea of wl_pointer.frame in general, but I don't like this
> >> > >>> part, because enter/leave really shouldn't be seen as pointer events at
> >> > >>> all. For example a window closing because of whatever reason will result
> >> > >>> in a wl_pointer.enter on the window that happened to be below. This has
> >> > >>> nothing to do with the pointer device, it is just about the pointer
> >> > >>> focus.
> >> > >>>
> >> > >>> The reason you have made the enter/leave events be dispatched state
> >> > >>> events to the frame event is, as you wrote above, to make it possible
> >> > >>> for extensions to extend the enter/leave events, but they can already do
> >> > >>> so by making those extensions latched events appending state to the
> >> > >>> enter or leave events. If we need to make some extension that adds
> >> > >>> something to receiving or loosing focus, I think they'd be worth their
> >> > >>> own events with their own semantics.
> >> > >>
> >> > >> I understand it's not pretty for the enter/leave semantics, but I'd argue
> >> > >> that it's potentially more confusing to have it to apply to all wl_pointer
> >> > >> events except enter/leave than just apply to all.
> >> > >
> >> > > I disagree. I see wl_pointer.frame to be the grouping of pointer events.
> >> > > The enter/leave are pointer *focus* events, and have nothing in
> >> > > particular to do with actual events from the pointer, making them
> >> > > different enough to make me feel they have very little in common with
> >> > > the rest of the events, thus are not suitable to be framed by
> >> > > wl_pointer.frame.
> >> >
> >> > They're quite similar in that they're coming from the same protocol
> >> > object.  What's the benefit in having a separate frame mechanism for
> >> > enter/leave should they need extension later?
> >> >
> >> > To me the focus events feel more like "seat" events than pointer events,
> >> > but they're still coming from the pointer object...
> >>
> >> The benefit is a clearer semantical difference, i.e. that enter/leave
> >> are *not* regular pointer events, they are strictly focus events, and
> >> that wl_pointer.frame frames events from the actual pointer.
> >
> > I think at this point the semantics of the frame in regards to enter/leave
> > is the only thing preventing this from being finished. Any chance we can
> > come to a conclusion here? Carlos, any opinion from the GNOME side of things
> > on the semantics? You already gave your rev-by but any specific comment on
> > this here?
> 
> FWIW, I do see the usefulness of having enter/leave under the same
> frame semantics. When we get around at doing an extension protocol to
> communicate more details about the current input device to apps, I'd
> expect the related event to be sent 1) when the pointer enters the
> surface and 2) anytime after when the user changes to another device.
> Of course nothing prevents this event from being sent together with
> both .enter and .frame, but strikes me as redundant.
> 
> I kind of see jonas' point, enter/leave are in the fine line between
> seat and pointer. IMHO, focus accounting could be seen as belonging to
> the seat (i.e. there's only one pointer focus per seat), but the
> events do belong on the device as these determine all the other events
> to be expected. It'd make sense to have all pointer events stick to
> the same event coalescing then.
> 
> >
> > Unfortunately, we're on too many different continents to make a jousting
> > tourney worthwhile.
> 
> Hope one more opinion helps somewhat...

It does make it clear that grouping both device events and focus events
with the same frame event is a more popular opinion than not so I guess
it's more or less decided what the conclusion is.


Jonas

> 
> Cheers,
>   Carlos