<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 10:34 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The frame event groups separate pointer events together. The primary use-case<br>
for this at the moment is diagonal scrolling - a vertical/horizontal scroll<br>
event can be grouped together to calculate the correct motion vector.<br>
Frame events group all wl_pointer events. An example sequence of motion events<br>
followed by a diagonal scroll followed by a button event is:<br>
wl_pointer.motion<br>
wl_pointer.frame<br>
wl_pointer.motion<br>
wl_pointer.frame<br>
wl_pointer.axis<br>
wl_pointer.axis<br>
wl_pointer.frame<br>
wl_pointer.button<br>
wl_pointer.frame<br>
<br>
In the future, other extensions may insert additional information about an<br>
event into the frame. For example, an extension may add information about the<br>
physical device that generated an event into the frame. For this reason,<br>
enter/leave events are grouped by a frame event too.<br>
<br>
The axis_source event determines how an axis event was generated. That enables<br>
clients to judge when to use kinetic scrolling. Only one axis_source event is<br>
allowed per frame and applies to all events in this frame.<br>
<br>
The axis_stop event notifies a client about the termination of a scroll<br>
sequence, likewise needed to calculate kinetic scrolling parameters.<br>
Multiple axis_stop events within the same frame indicate that scrolling has<br>
stopped in all these axis at the same time.<br>
<br>
The axis_discrete event provides the wheel click count. Previously the axis<br>
value was some hardcoded number (10), with the discrete steps this enables a<br>
client to differ between line-based scrolling on a mouse wheel and smooth<br>
scrolling with a touchpad.<br>
<br>
We can't extend the existing wl_pointer.axis events so we introduce a new<br>
concept: latching events. These events (currently only axis_discrete)<br>
are prefixed before a wl_pointer.axis event. A client must build the full<br>
state of the event until the respective top-level event arrives.<br>
i.e. a single event frame for a diagonal scroll with discrete information may<br>
be:<br>
<br>
wl_pointer.axis_source<br>
wl_pointer.axis_discrete<br>
wl_pointer.axis<br>
wl_pointer.axis_discrete<br>
wl_pointer.axis<br>
wl_pointer.frame<br></blockquote><div><br></div><div>This description is a little confusing. Actually it looks like a client can ignore the axis events entirely, the information it needs is in the discrete events. This description makes it sound like the movement must be determined by examining the axis event.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Signed-off-by: Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>><br>
---<br>
Changes to v4:<br>
- axis argument added to axis_discrete. While technically redundant since<br>
  the axis event carries this information, the lack of this argument leads<br>
  to awkward client-side implementation. A single uint32_t value with no<br>
  other information attached had to be stacked in a temporary variable, only<br>
  the next event can then tell us whether the event was x or y scroll.<br>
  Providing the axis in the discrete event means we can immediately stack<br>
  this into the right variable.<br></blockquote><div><br></div><div>Yea it does sound like you are altering the discrete event into a stand-alone event, I think this is correct.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- the big change is the rename from axis_frame to wl_pointer.frame.<br>
  the axis_frame concept was solid but working on other things Carlos and I<br>
  discovered that we may need to add additional information to some events.<br>
  A generic wl_pointer.frame event gives us the same benefit of the<br>
  axis_frame but allows to insert events (even from other extensions)<br>
  into a specific frame and augment that event.<br></blockquote><div><br></div><div> I think you might want to expand this even further, making the "frame" event per-seat, or per client connection. It could then be used to group other events into units, similar to how the commit request works in the other direction.<br><br></div></div><br></div></div>