This note doesn't add anything, the delta to the last changed is the same as
the delta to the last event, otherwise it'd be 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For start/end, dx/dy is always 0.0, and there is no need to make calling this
function for start/end a caller bug. It just unnecessarily complicates the
caller's codepath.
Same for get_angle
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Extend the touchpad gesture API with pinch gestures. Note that this
new API offers a single event stream for both pinch and rotate data, this
is deliberate as some applications may be interested in getting both at
the same time. Applications which are only interested in one or the other
can simply ignore the other.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
For touchscreens we always send raw touch events to the compositor, and the
compositor or application toolkits do gesture recognition. This makes sense
because on a touchscreen which window / widget the touches are over is
important context to know to interpret gestures.
On touchpads however we never send raw events since a touchpad is an absolute
device which primary function is to send pointer motion delta-s, so we always
need to do processing (and a lot of it) on the raw events.
Moreover there is nothing underneath the finger which influences how to
interpret gestures, and there is a lot of touchpad and libinput configuration
specific context necessary for gesture recognition. E.g. is this a clickpad,
and if so are softbuttons or clickfinger used? What is the size of the
softbuttons? Is this a true multi-touch touchpad or a semi multi-touch touchpad
which only gives us a bounding box enclosing the fingers? Etc.
So for touchpads it is better to do gesture processing in libinput, this commit
adds an initial implementation of a Gesture event API which only supports swipe
gestures, other gestures will be added later following the same model wrt,
having clear start and stop events and the number of fingers involved being
fixed once a gesture sequence starts.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a
1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel
jumps. It is impossible for the caller to detect whether the jump was caused
by a single motion or multiple motion events.
This is technically an API break, but not really.
The accelerated data was already relatively meaningless, even if normalized as
the data did not correspond predictably to any input motion (unless you know
the implementation acceleration function in the caller). So we can drop the
mention from there without expecting any ill effects in the caller.
The unaccelerated data was useless for low-dpi mice and could only be used to
measure the physical distance of the mouse movement - something not used in
any caller we're aware of (if needed, we can add that functionality as a
separate call). Dropping motion normalization for unaccelerated deltas also
restores true dpi capabilities to users of that API, mostly games that want to
make use of high-dpi mice.
This is a simplified patch, the normalization is still in place for most of
libinput, it merely carries the original coordinates in the event itself.
In the case of touchpads, the coordinates are unnormalized into the x-axis
coordinate space as per the documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In some applications, notably Inkscape, where it is common to frequently drag
objects a short distance the default to drag-lock always-on is frustrating for
users.
Make it configurable, with the current default to "on".
New API:
libinput_device_config_tap_set_drag_lock_enabled
libinput_device_config_tap_get_drag_lock_enabled
libinput_device_config_tap_get_default_drag_lock_enabled
Any device capable of tapping is capable of drag lock, there is no explicit
availability check for drag lock. Configuration is independent, drag lock may
be enabled when tapping is disabled.
In the tests, enable/disable drag-lock explicitly where the tests depend
on it.
https://bugs.freedesktop.org/show_bug.cgi?id=90928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Similar to libinput_device_pointer_has_button(), this function returns whether
a given device has a specific keycode.
This enables a caller to determine if the device is really a keyboard (check
for KEY_A-KEY_Z) or just a media key device (check for KEY_PLAY or somesuch),
depending on the context required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Adds the following quartett of functions to enable/disable middle mouse button
emulation on a device:
libinput_device_config_middle_emulation_is_available()
libinput_device_config_middle_emulation_set_enabled()
libinput_device_config_middle_emulation_get_enabled()
libinput_device_config_middle_emulation_get_default_enabled()
This patch only adds the config framework, it is not hooked up to anything
yet.
Note: like other features this is merely the config option, some devices will
provide middle button emulation without exposing it as configuration. i.e. the
return value of libinput_device_config_middle_emulation_is_available() only
tells you whether you can _configure_ middle button emulation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't actually use TOUCH_CANCEL in libinput, but either way calling the
slot on a cancel should be valid. Calling it on a FRAME event is not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And merge all current API versions into the same block. This isn't technically
necessary since removing libinput_has_button from the code will remove it from
the exported list. That trips up test/symbols-leak-test though.
Since we break the API and bump the soname in this release anyway, move
to a single block so the initial stable API is all nicely grouped together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake proximity events are context dependent and libinput doesn't have access
to the context. For example, fake proximity on the Wacom mouse is only required
in relative mode - but whether to use relative or absolute events is decided
in the caller.
Document what the recommended approach is since it's a bit quirky and leave it
at that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Equivalent to the pointer axis function - it gets the mouse wheel clicks from
the tablet mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Providing a relative axis in the axis_get_value() is inconsistent with the
other axes, this will be fixed in a follow-up commit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
The little wheel isn't a full wheel, it has a ~90 degree rotation angle with a
range of 1024 values. To avoid confusion with "wheel" elsewhere in the API
name it slider.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
Needs to be calculated from the x/y tilt values, the mouse has a fixed offset
of 175 degrees counterclockwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
libwacom can tell us how many buttons we have per stylus, so we map those into
BTN_STYLUS and BTN_STYLUS2.
BTN_TOUCH is set on all styli.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
The tool ID on wacom tablets is what really defines the tool, so one can
differ between say an Intuos Grip Pen, Art Pen or Classic Pen. They're all
BTN_TOOL_PEN in the kernel driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
It's a rough guide only, but still precise enough to make some decisions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
There's no real reason to keep them in sync but it has drawbacks when we start
introducing tools that the kernel doesn't have (and can't easily add due to
range constraints).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
This is only used internally.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Stephen Chandler Paul <thatslyude@gmail.com>
