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

[Carlos Garnacho]

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

Cheers,
  Carlos