This event is just used to notify the caller when the tool's no longer in
proximity. When an event like this occurs, everything from evdev up until the
next EV_SYN event is discarded along with any events that occured since the last
EV_SYN event. This also silences any tool update events where the tool type is
changed to LIBINPUT_TOOL_NONE, so we don't end up filling the tool list with a
bunch of tools that aren't actually tools.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will be used to represent a tool in use on a drawing tablet.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices set the LIBINPUT_DEVICE_CAP_TABLET flag, and emit a lot more axis
information then mice and touchpads. As such, tablet events are in a whole new
group of events that is separate from everything else.
In this commit, only X and Y axes are reported in libinput.
Based off the patch originally written by Carlos Garnacho
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This capability flag would be enabled when events are driven through
a stylus, ie. on a tablet.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
Almost all non Apple touchpads have visible markings for software button areas,
so limit clickfinger behavior to Apple clickpads, and implement software button
areas for others.
This is a slightly fancier implementation than the simplest model and ported
over from libtouchpad. It implements a state machine for the software buttons
with left and right buttons currently implemented. Buttons are oriented
left-to-right, in a horizontal bar. No random button placement allowed.
In general, the procedure is:
- if a finger sets down in the left button area, a click is a left click
- if a finger sets down in the right button area, a click is a right click
- if a finger leaves the button area, a click is a left click
- if a finger starts outside the button area, a click is a left click
Two timeouts are used to handle buttons more smoothly:
- if a finger sets down in a button area but "immediately" moves over
to a different area, that area takes effect on a click.
- if a finger leaves a button area and "immediately" clicks or moves back into
the area, the button still takes effect on a click.
- if a finger changes between areas and stays there for a timeout, that area
takes effect on a click.
Note the button area states are named BOTTOM_foo to make it easier to later
add support for a top button area such as can be found on the Thinkpad [2-5]40
series.
Co-authored-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
A few functions only work on the base event but once we've converted to the
target event we can't go back. Casting works for now but that would expose
internal ABI.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Previous return value was the straight ioctl, we should try to avoid errno
mangling.
This changes the API, if not the ABI. Callers with code along the lines of
if (libinput_device_get_keys() == -1) will now break.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
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>
Since a Wayland compositor have to represent all touch devices of a seat
as one virtual device, lets make that easier by also providing seat wide
slots with touch events.
Seat wide slots may be accessed using
libinput_event_touch_get_seat_slot().
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The previous log handler wasn't actually hooked up to anything. Add a public
API for the log handler with priority filtering, defaulting to priority
'error' and stderr as output stream.
And to keep the diff down and convenience up, provide a few simple wrappers
for logging. The generic is log_msg(), but let's use log_info, log_error, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
It is unclear what "current" means as events are asynchronous, and
since a slot is associated with a touch event rather than a device,
change the description to reflect this.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
With this patch, a user can keep a reference to a libinput_seat
instance, which will cause the seat to never be unlinked from the
libinput context nor destroyed.
Previously, a when the last device of a seat was removed, the seat was
unlinked and if a new device was discovered with a previously empty seat
a new seat instance would always be created, meaning two potential seat
instances with identical physical and logical seat name pairs.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Creates an empty context that is not hooked up to a device. Callers can then
add and remove devices to this context using libinput_path_add_device() and
libinput_path_remove_device().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This allows multiple devices to share a single libinput context. The new
function returns the newly added device immediately. Unlike the udev seat
where devices may or may not be added - over the lifetime of the seat - a
path-based backend knows immediately if device exists or doesn't exist.
Returning the device is required by callers that have the event processing
separate from adding devices - by the time we have the DEVICE_ADDED event in
the queue we may have other events to process first. And the DEVICE_ADDED
event won't easily link to the path we gave it anyway, so it's hard to figure
out which DEVICE_ADDED event corresponds to the new device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The event represent pointer motions on a screen, so this information is
unnecessary. It could also be confused for meaning the provided
coordinate's direction being device specific.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Instead of automatically transforming absolute coordinates of touch and
pointer events to screen coordinates, the user now uses the corresponding
transform helper function. This means the coordinates returned by
libinput_event_pointer_get_absolute_x(),
libinput_event_pointer_get_absolute_y(), libinput_touch_get_x() and
libinput_touch_get_y() has changed from being in output screen coordinate
space to being in device specific coordinate space.
For example, where one before would call libinput_event_touch_get_x(event),
one now calls libinput_event_touch_get_x_transformed(event, output_width).
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
By specifying that a device will not be read until the next time the
user calls libinput_dispatch(), if data is available, it will allow for
setting up initial configuration, such as tap button, output screen
size, acceleration parameters, etc.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
These events are not a state of a single touchpoints but rather a notification
that all touchpoints finished processing. As such, they should have their own
type.
And make sure we actually send them when needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slightly enhances the type-safety. A caller may now do something along the
lines of
struct libinput_event_pointer *ptrev;
ptrev = libinput_event_get_pointer_event(event);
if (!ptrev)
oops, that wasn't a pointer event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The event type itself says enough about the actual event type, we don't need
to have separate structs for every type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Provide one top-level event for keyboard events: libinput_event_keyboard. The
event type specifies which subtype the event is anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that the target of an event isn't exposed to the caller anymore, the
namespacing can be associated with a more intuitive one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replaced by specific accessor functions for context, seat and device. This
obsoletes the internal target as well, we just direcly ref the element we need
to instead of temporarily storing it in the target.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After dropping seat evens, all events are now are associated with a device, so
provide a generic accessor function and drop the custom ones.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
seats are more a compositor concept than a concept of the input library. All
devices in a libinput context are associated with the seat given on creation
of the seat (maps to ID_SEAT in udev for the udev backend).
A logical seat may be assigned to a device (e.g. WL_SEAT) but this does not
necessarily map to the creation of the seat in the compositor.
Drop the seat events but keep seat objects around so that the caller can still
identify which seat a device belongs to.
If the libinput_seat_unref() in the udev backend destroys the seat, the device
list of that seat is invalid and we'd be accessing already freed bytes. To
avoid this, ref the seat before the device removal loop, then unref it once
we're done - that unref then may trigger the actual removal of the seat.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
