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>
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>
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>
Two methods are provided:
* button area - used on most clickpads, a click with a touch within a given
area generates left/middle/right clicks
* clickfinger - used on apple touchpads, a click with 1/2/3 fingers on the
touchpad generates a left, right, middle click
Both methods already exist in the touchpad code, this is just the
configuration interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices require more than just flipping around the buttons, such as
tablets.
When it comes to devices like tablets, because the position of the palm rest is
on the right, the entire tablet has to be flipped around in order to be usable
by lefties. As such, this requires that we reverse the coordinates of the
tablets in addition to flipping the buttons on the tablet. As such, renaming
these functions so that they aren't specific to devices where only the buttons
are flipped seems appropriate.
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>
This is merged on top of the wheel normalization patches. Those introduced an
axis source and an extra "discrete" value to the various internal and external
APIs. This branch changed from a single value to passing dx/dy into all scroll
events.
The conflicts are to change everything to take x, y, x_discrete, y_discrete as
values (and the source axis mask of course).
Conflicts:
src/evdev-mt-touchpad-edge-scroll.c
src/evdev.c
src/libinput-private.h
src/libinput.c
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 a discrete value 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.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Sending separate axis events instead of one unified events is limiting,
especially when simultaneously scrolling in both directions and the caller
tries to implement kinetic scrolling.
Take a page from the tablet-support branch and instead implement the axis
event as a generic event that can contain multiple axes simultaneously.
Right now we only have two (scroll) axes and we could easily just check both
for non-zero values. If we want to allow further axes in the future, we need
a check whether an axis is set in an event, that's what
libinput_event_pointer_has_axis to scroll events() is for.
We also need the mask to notify of a scroll stop event, which could otherwise
be confused as a vertical-only or horizontal-only event.
This is an API and ABI break.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Similar to the mouse resolution, let's make the scroll distance a sensible
predictable value. Most mice use a 15 degree angle per scroll click, so let's
change to that. This will alter behaviour in clients that expect 10.
We return doubles for the axis value, so that leaves the option of
really fine-grained step sizes in the future.
We currently assume all mice have 15 degree angles. Like the DPI settings, it
will require a udev property to be set. Patch for that to follow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Discreet means to not draw attention.
Discrete means non-continuous.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For a caller to implement/provide kinetic scrolling ("inertial scrolling",
"fling scrolling"), it needs to know how the scrolling motion was implemented,
and what to expect in the future. Add this information to the pointer axis
event.
The three scroll sources we have are:
* wheels: scrolling is in discreet steps, you don't know when it ends, the
wheel will just stop sending events
* fingers: scrolling is continuous coordinate space, we know when it stops and
we can tell the caller
* continuous: scrolling is in continuous coordinate space but we may or may not
know when it stops. if scroll lock is used, the device may never technically
get out of scroll mode even if it doesn't send events at any given moment
Use case: trackpoint/trackball scroll emulation on button press
The stop event is now codified in the API documentation, so callers can use
that for kinetic scrolling. libinput does not implement kinetic scrolling
itself.
Not covered by this patch:
* The wheel event is currently defined as "typical mouse wheel step", this is
different to Qt where the step value is 1/8 of a degree. Some better
definition here may help.
* It is unclear how an absolute device would map into relative motion if the
device itself is not controlling absolute motion.
* For diagonal scrolling, the vertical/horizontal terminator events would come
in separately. The caller would have to deal with that somehow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Original patch, before the rebase onto today's master:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Previously, the pointer could only be passed into the context on creation
time and was immutable after that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike all other structs, events aren't refcounted and will get destroyed
immediately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Makes them show up on the respective page and in the data structures list
doxygen generates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
doxygen supports markdown so we can expand the README with general interesting
information in markdown format and have it be the front page of the
documentation at the same time.
This requires renaming README to README.txt, but that's a relatively small
price to pay.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allow retrieval of the libinput context from the seat and the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The libinput device abstracts a number of things but sometimes the underlying
device is important. The udev device provides the necessary handle to access
that underlying device and various sysfs properties that may be necessary.
A function returning the device node would've done the same thing but is more
prone to race conditions than the udev_device.
https://bugs.freedesktop.org/show_bug.cgi?id=85573
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The seat of a device is currently immutable, but a device may (in a
multi-pointer case) move between different logical seats. Moving it between
seats is akin to removing it and re-plugging it, so let's do exactly that.
The physical seat name stays immutable.
Pro:
- device handling after changing a seat remains identical as handling any
other device.
Con:
- tracking a device across seat changes is difficult
- this is not an atomic operation, if re-adding the device fails it stays
removed from the original seat and is now dead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
