<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 4:02 AM, Auke Booij <span dir="ltr"><<a href="mailto:auke@tulcod.com" target="_blank">auke@tulcod.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><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></div></div></blockquote><div><br></div><div>Since the "frame" event groups everything together, it does not seem like there is a need to talk about "latching". _descrete events are "latching" in that they are in the same frame. This could remove some complexity from your description I think.<br><br></div><div>Objections I see is that it makes it impossible to have both discreet and non-discreet axis events in the same frame, but I find it hard to imagine an input device where this would be physically possible. Also that this allows the order to be random rather than forcing the discrete events to be immediately before the axis, but I don't see any way a useful client could take advantage of this (a client is pretty much forced to accumulate the information in a structure until the frame event happens, so enforced ordering is of no help).<br><br></div></div></div></div>