Change vector_get_direction input to a normalized_coords type rather than
passing in a separate x,y pair, and rename it normalized_get_direction to
match. Since it now depends on the normalized_coords type which gets declared
in libinput-private.h also move it to libinput-private.h .
Note this commit also contains a functional change wrt the get_direction
usuage in the palm detection. The palm-detection code was calling get_direction
on non normalized coordinates, this commits changes the code to normalize
the coordinates first. This is the right thing to do as calling get_direction
on non normalized coordinates may result in a wrong direction getting returned
when the x and y resolution of the touchpad are not identical.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
What we really need is not a specific delta type, but a type which can hold
non discrete device coordinates, this is e.g. also needed for the center
coordinates of gestures. So rename delta_coords to device_float_coords to
properly reflect what we really need.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_is_zero helper function, and use it where applicable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a normalized_length helper function and use this where applicable,
just a minor cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_normalize_coords is one of the last functions taking separate x, y
values rather a coordinate pair, this commit cleans this up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make it clear where we're dealing with device coordinates and where we're
dealing with DPI-normalized coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
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>
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>
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>
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>
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>
Add a configuration option to allow selecting between 2-finger / edge / none
scrolling (for touchpads).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For features like e.g. disable-touchpad-while-typing, it is necessary for one
device to be able to listen into another device's events.
It is tempting to use the existing device_added / device_removed mechanism
to give e.g. the keyboard a link to the touchpad, and make the keyboard code
disable / re-enable the touchpad but this is wrong. This needs to be a setting
of the touchpad, and the policy for things like which events to count as
activity, and what sort of timeout to use to consider the device idle, belongs
in the touchpad code not in the keyboard code.
Add an event listeners mechanism so that the touchpad can listen for (e.g.)
keyboard events, and respond to these itself.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The libinput evdev code uses 64 bit timestamps internally, to avoid having to
deal with timestamp wraps. The internal foo_notify_bar functions time argument
however is only 32 bits, bump this to 64 bits to avoid truncating the timestamps
when calling these functions.
This is a preparation patch for adding internal event listeners, so that the
callbacks for these can get the full 64 bit timestamps.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Natural scrolling is simply inverted scrolling, but I decided to
use the Apple terminology simply because it's easier to google for.
Add the usual quartett of config options for has/set/get/get_default/, as a
boolean option rather than an enum for scroll mode to avoid name collusion
with the (currently in the works) edge scrolling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only exposes one knob - speed, normalized to a [-1, 1] range with 0 being the
neutral "this is what we think is normal" speed. -1 and 1 reflect the
slowest/fastest reasonable speed on this device.
Note: with this API we commit to having any pointer accelerating as a true
gliding scale. We cannot map the [-1,1] range into a discrete set of steps
as we do not communicate to the caller whether a specific value has changed
the acceleration. Without that, a caller may assume that acceleration has
changed even when it is not visible to the user.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Rather than adding a config interface to disable a device merely allow a
caller to toggle the "send events" mode on the device. If off, the device
won't send events (though further events may be received depending on the
current state of the device).
Default is enabled, i.e. the device sends events.
A special mode is added to the obvious enable/disable: disable the device when
an external mouse is connected. Once set, the device will be enabled when no
mouse is present and stop sending events otherwise. This isn't hooked up to
anything yet though.
Built into the config API is the default option of "enabled". Any device
supports this, for the obvious reason. Disabling or conditionally disabling is
left to the implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
New configuration API:
libinput_device_config_calibration_has_matrix()
libinput_device_config_calibration_set_matrix()
libinput_device_config_calibration_get_matrix()
libinput_device_config_calibration_get_default_matrix()
Deprecates libinput_device_calibrate().
For coordinate transformation, we're using a precalculated matrix. Thus, to
support ..._get_matrix() we need to store the original user-specified matrix
separately, in an unmangled state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
More expressive in the caller and less ambiguous about return values (is it 1?
is it non-zero? can it be negative?)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Provide an interface to enable/disable tapping, with a default mapping of
1/2/3 fingers mapping to L/R/M button events, respectively.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Instead of only allowing one owner keeping a libinput context alive,
make context reference counted, replacing libinput_destroy() with
libinput_unref() while adding another function libinput_ref().
Even though there might not be any current use cases, it doesn't mean we
should hard code this usage model in the API. The old behaviour can be
emulated by never calling libinput_ref() while replacing
libinput_destroy() with libinput_unref().
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>
Rather than a single global logging function, make the logging dependent on
the individual context. This way we won't stomp on each other's feet in the
(admittedly unusual) case of having multiple libinput contexts.
The userdata argument to the log handler was dropped. The caller has a ref to
the libinput context now, any userdata can be attached to that context
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
e912d620d0 changed from POINTER_BUTTON_STATE to
simply BUTTON_STATE, replicate that for key events too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is useful for when we use libraries which want us to provide them with
a logging callback.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently we are using DIY timers in the touchpad softbutton and tap handling
code, and at least the softbutton code gets its wrong. It uses one timer-fd
per touchpad to set a timeout per touch, which means that if a timeout is
set for 100ms from now for touch 1, and then 50 ms later touch 2 sets a timeout
for 200 ms from now, then the timeout for touch 1 will come 150 ms too late.
This commits adds a proper timer subsystem so that we've one place to deal
with timer handling, and so that we can only get it wrong (well hopefully
we get it right) in one place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Button states are applicable to more then just the pointer, so having a
non-generic name name for a generic enumerator value like
libinput_pointer_button_state doesn't make sense. Changing it to something
generic like libinput_button_state allows it to be reused by other devices that
may potentially be added to libinput in the future.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixed point numbers can easily overflow, and double to fixed point
conversion is lossy. Use floating point (double) where fixed point
numbers where previously used and remove the li_fixed_t type.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoids having to #define any values we're trying to use.
Header file is from Linux 3.15-rc8.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
When we knowingly hit a bug, we should know what the bug is caused by. Log
that in a standardized fashion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Compositors will need to keep provide virtual devices of supported
generic device types (pointer, keyboard, touch etc). Events from each
device capable of a certain device type abstraction should be combined
as if it was only one device.
For key and button events this means counting presses of every key or
button. With this patch, libinput provides two new API for doing just
this; libinput_event_pointer_get_seat_button_count() and
libinput_event_keyboard_get_seat_key_count().
With these functions, a compositor can sort out what key or button events
that should be ignored for a virtual device. This could for example
look like:
event = libinput_get_event(libinput);
switch (libinput_event_get_type(event)) {
...
case LIBINPUT_EVENT_POINTER_BUTTON:
device = libinput_event_get_device(event);
seat = libinput_event_get_seat(device);
pevent = libinput_event_get_pointer_event(event);
if (libinput_event_pointer_get_button_state(pevent) &&
libinput_event_pointer_get_seat_button_count(pevent) == 1)
notify_pointer_button_press(seat);
else if (libinput_event_pointer_get_button_state(pevent) &&
libinput_event_pointer_get_seat_button_count(pevent) == 0)
notify_pointer_button_release(seat);
break;
...
}
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For logging when things happen which should not happen. We may want to do
something more fancy in the future but for now this suffices.
Modelled after log_bug in libevdev.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of having one touch events representing different types of touch
events by providing a touch type, have one separate event type per touch
type. This means the LIBINPUT_EVENT_TYPE_TOUCH is replaced with
LIBINPUT_EVENT_TYPE_TOUCH_DOWN, LIBINPUT_EVENT_TYPE_TOUCH_MOTION,
LIBINPUT_EVENT_TYPE_TOUCH_UP and LIBINPUT_EVENT_TYPE_TOUCH_CANCEL.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
