<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - RFE: Need way to report start of finger scroll"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=99415#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - RFE: Need way to report start of finger scroll"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=99415">bug 99415</a>
              from <span class="vcard"><a class="email" href="mailto:carlosg@gnome.org" title="Carlos Garnacho Parro <carlosg@gnome.org>"> <span class="fn">Carlos Garnacho Parro</span></a>
</span></b>
        <pre>(In reply to Peter Hutterer from <a href="show_bug.cgi?id=99415#c6">comment #6</a>)
<span class="quote">> I guess the main issue I have with this is that we can't drop the "scroll is
> 0 on stop" without breaking backwards compatibility, so if we send a scroll
> stop event, we'd be sending the same information twice and guarantee that it
> always gets ignored. Leaving it out would result in perceived asymmetrical
> event stream. That's a bit unfortunate.</span >

Absolutely, but it's just unfortunate :), once a compositor moves to the newer
event to trigger kinetic scroll, a 0-distance axis event would be transparently
ignored.

<span class="quote">> 
> But otherwise, it'd be a LIBINPUT_EVENT_POINTER_AXIS_START and
> LIBINPUT_EVENT_POINTER_AXIS_CANCEL, sent only for some pointer sources. The
> former is relatively trivial, the latter is the one that needs the detailed
> work to avoid breaking backwards compatibility.</span >

I find those names a bit confusing... Not sure if I'm getting the equivalences
right, but on AXIS_START the client is supposed to stop kinetic scrolling,
while on AXIS_CANCEL it does start it?

I guess it's the word "cancel" what troubles me, as it implies something that
can be easily mistaken for its counterpart. I think AXIS_START/AXIS_END are
more symmetric and have less connotations about the effect they're meant to
produce. It still doesn't sound entirely alright for the times they're emitted
unpaired (eg. before 2fg gestures), the oddity might be solved though if we
ensure to emit both start+end before handling it as a gesture.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>