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>
This constant isn't used in the public API, let's drop it. To make it easier
to use it internally and avoid accidental boolean comparisions with axes, bump
all real axes up to start at 1.
Internally that means we drop the AXIS_CNT since it'd be misleading and
instead use MAX or MAX + 1 everywhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Having a motion event that's sent right after the original proximity event just
to give the values of each axis is somewhat redundant. Since we already include
the values of each axis with each type of event, we may as well use the
proximity event to give the client the starting values for each axis on the
tablet.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There isn't much purpose in having proximity in and out as different events,
combining them into one single event is more consistent with the rest of the
API, and means less code for clients to have to work with.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Store it as identifier in the device group, any two devices that have a
the same non-NULL identifier share the group.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device has multiple capabilities, has_button is imprecise. A device with
tablet and pointer capability for example may have BTN_LEFT on the pointer
interface but not on the tablet interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Added: udev-tag detection for the tablet.
libwacom assigns ID_INPUT_TABLET to all known devices but also
ID_INPUT_TOUCHPAD to all known devices with a touch interface. That's a bug
and should be fixed there but we can work around it by checking both and
making sure only one is set.
Conflicts:
src/evdev.c
test/misc.c
Devices like Wacom tablets have multiple event nodes (touch, pad and stylus).
This requires some logical grouping, e.g. setting an Intuos 5 tablet
left-handed effectively turns it upside down. That then applies to both the
stylus and the touch device.
Merging the devices into one struct libinput_device is not feasable, it
complicates the API for little benefit. A caller would still need access to
all subdevices to get udev handles, etc. Some configuration options apply to
the whole device (left-handed) but some (may) only apply to a single subdevice
(calibration, natural scrolling).
Addressing this would make the libinput API unwieldly and hard to use.
Instead, add a device group concept. Each device is a member of a device
group - a singleton for most devices. Wacom tablets will have a single group
across multiple devices, allowing the caller to associate the devices together
if needed.
The API is intentionally very simple and requires the caller to keep track of
groups and which/how many devices are in it. The caller has more powerful
libraries available to do that than we have.
This patch does not address the actual merging of devices into the same
device group, it simply creates a new group for each new device.
[rebased on top of 0.10]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
