From the "Smooth Scrolling" section of [XI2Proto.txt][1]:
> One unit of scrolling in either direction is considered to be equivalent to
> one button event, e.g. for a unit size of 1.0, -2.0 on an valuator type
> Vertical sends two button press/release events for button 4. Likewise, a
> button press event for button 7 generates an event on the Horizontal
> valuator with a value of +1.0. The server may accumulate deltas of less than
> one unit of scrolling.
From [What's new in XI 2.1 - smooth scrolling][2]:
> The increment defines what delta the driver considers to be one scroll
> event. For an increment of +5, each delta of 5 should be regarded as one
> scroll unit down. For an increment of -3, each delta of 3 should be regarded
> as one scroll unit up (i.e. inverted).
[1]: http://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt
[2]: http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html
This fixes scrolling with my Microsoft mouse in X11 on Debian 8.1.
wait_event used to call nextEventMatchingMask twice. Once with untilDate:distantFuture,
and dequeue:NO to wait until the next event but witout consuming it, and again with
untilDate:distantPast and dequeue:YES to retrieve the event (via poll_events).
For some reason, with osx 10.11, calling nextEventMatchingMask with dequeue:NO never
returns if the user scrolls, freezing the app.
So we now call nextEventMatchingMask only once, with dequeue:YES.
Integrate with wayland-window crate to draw decorations
allowing resize & move of the window.
Leaving the wayland backend as disabled until full usability
is ensured.
fixes#314 for me.
I've "tested" change by running examples (which prior to change simply
crashed), but since I did not run those examples successfuly ever before,
I don't know whether they worked as intended.
XInput2 has a concept of master and slave devices,
where a slave device is the actual physical device,
attached to a master device representing the cursor or keyboard
focus.
See http://who-t.blogspot.co.uk/2009/05/xi2-recipes-part-1.html
Mouse events were being received from both the master and slave
devices, but we are only interested in events from the master device.
Fixes#533
