[PATCH libinput] Add libinput_event_pointer_get_axis_click_count() to count wheel clicks

[Bill Spitzak]

This is great and addresses my problem with the Windows API mentioned in 
a previous email. Guess I should have looked at all the posts before 
responding.

On 01/13/2015 12:01 AM, Peter Hutterer wrote:
> On Tue, Jan 13, 2015 at 03:12:24PM +0800, Jonas Ådahl wrote:
>> On Tue, Jan 13, 2015 at 03:21:24PM +1000, Peter Hutterer wrote:
>>> The recent normalization of wheel events means we get the angle in degrees but
>>> we don't know how this corresponds to clicks. The M325 has a 20 degree click
>>> angle, most other mice have 15 degrees. So an angle of 60 can be 3 or 4 click
>>> events.
>>>
>>> Most clients care more about the click count than the angle on a mouse wheel.
>>> Provide that value when needed.
>>>
>>> Adding click_count to the axis event leaves the possibility of defining
>>> discrete units for finger/continuous scroll sources in the future. Right now,
>>> these will always reuturn 0.

>> Since clicks is a count, not a vector, it should have no direction
>> right? Meaning natural or not, a click count should always be > 0.

No, if it was an unsigned count then an event that consolidated the user 
moving the wheel 3 up and 2 down would report 5, which is certainly not 
going to produce the motion the user intended! So it is a sum of signed 
values and it makes sense to return the signed result.

>> I assume the choice of using double to represent a click was deliberate,
>> but considering that counting usually means integer numbers, it would be
>> nice with some clarification what non-integer counts means.
>
> two reasons:
> consistency - the other pointer axis bits return doubles
> option of "subpixel clicks" in the future. Not sure how that'll work
> exactly, but if we have a click count for an otherwise continuous source, it
> could be that a distance covered is equivalent to 2.5 clicks.
> I don't have a use-case for this, and haven't thought much about how this
> would work out exactly though.

If there is actual tactile feedback for the clicks this is going to have 
to return an integer, otherwise any click-based output by the client 
will not be in sync with the actual clicks.

I supposed it would work for a continuous wheel that has no physical 
clicking.