The issue was that touch::down event from the compositor to client apps
would send the previous motion events coordinates and this obviously made
the client do the wrong thing. This happened because we were not waiting
for a SYN event to come from evdev before sending down, motion or up events.
https://bugs.freedesktop.org/show_bug.cgi?id=51909
The original code would overrun since the calculation of the range did not
take into consideration the size of the entries in the table.
Cc:Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Rob Bradford <rob@linux.intel.com>
The original code always set the finger_state to the appropriate bitmask
irrespective of whether the event was a press or a release. It would also blat
all members of the bitmask rather than ORing in the new bit for the event.
Cc:Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Rob Bradford <rob@linux.intel.com>
As said by krh: "Maybe we should also just call it an evdev_device
instead, shorter [and] not really ambiguous."
[krh: if my typo filled irc is going in a commit message, I'm at least going
to insert the missing words.]
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Instead of using a uint32_t for state everywhere (except on the wire,
where that's still the call signature), use the new
wl_pointer_button_state enum, and explicit comparisons.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Touchpad related code has been rewritten and moved to its own file
accessed by evdev via the dispatch interface.
The various functionality implemented are anti-jitter (don't jumping
around), smoother motions, touch detection, pointer acceleration and
some more.
Pointer acceleration is implemented as one generic part, and one touch
specific part (a profile).
Some ideas and magic numbers comes from xserver and
xf86-input-synaptics.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>