libinput/src/evdev.h

597 lines
16 KiB
C
Raw Normal View History

/*
* Copyright © 2011, 2012 Intel Corporation
* Copyright © 2013 Jonas Ådahl
* Copyright © 2013-2015 Red Hat, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
#ifndef EVDEV_H
#define EVDEV_H
#include "config.h"
#include <stdbool.h>
#include "linux/input.h"
#include <libevdev/libevdev.h>
#include "libinput-private.h"
#include "timer.h"
#include "filter.h"
/*
* The constant (linear) acceleration factor we use to normalize trackpoint
* deltas before calculating pointer acceleration.
*/
#define DEFAULT_TRACKPOINT_ACCEL 1.0
/* The fake resolution value for abs devices without resolution */
#define EVDEV_FAKE_RESOLUTION 1
enum evdev_event_type {
evdev: Only track one pending event Instead of having a mask of pending events there is now an enum with a single value to represent the one pending event. The event gets flushed explicitly as part of the handling code for each event type rather than in the outer event reading loop. The pending event is used so that we can combine multiple motion events into one and to make sure that we have recieved the latest position before sending a touch up or down event. This should fix the following problems with the old approach: • If you release a finger and press it down again quickly you could get the up and down events in the same batch. However the pending events were always processed in the order down then up so it would end up notifying two down events and then an up. The pending event is now always flushed when there is a new up or down event so they will always be in the right order. • When it got a slot event it would immediately change the slot number and then set the pending event. Then when it flushed the events it would use the new slot number to flush the old pending event so the events could have the wrong finger. The pending event is now immediately flushed when a slot event is received so it will have the right finger. • If you get more than 32 events in one read then it was resetting the pending events before processing the next batch in evdev_process_events. If four fingers were pressed down at once then it ended up with more than 32 events and the sync message would be in the second batch. The pending flag for the last finger was getting cleared so it never got emitted. In this patch the pending event is no longer reset after reading nor is it explicitly flushed. Instead it is flushed when we receive a EV_SYN event or a different pending event needs to replace it. The touchpad handling code was trying to use the pending event mechanism to notify the relative motion events. I'm not sure why it was doing this because it looks the event would effectively get emitted as soon as the touchpad_process function is finished anyway and it wasn't accumulating the values. Instead I've just changed it to emit the event directly. https://bugs.freedesktop.org/show_bug.cgi?id=67563
2013-09-24 12:09:03 +01:00
EVDEV_NONE,
EVDEV_ABSOLUTE_TOUCH_DOWN,
evdev: Only track one pending event Instead of having a mask of pending events there is now an enum with a single value to represent the one pending event. The event gets flushed explicitly as part of the handling code for each event type rather than in the outer event reading loop. The pending event is used so that we can combine multiple motion events into one and to make sure that we have recieved the latest position before sending a touch up or down event. This should fix the following problems with the old approach: • If you release a finger and press it down again quickly you could get the up and down events in the same batch. However the pending events were always processed in the order down then up so it would end up notifying two down events and then an up. The pending event is now always flushed when there is a new up or down event so they will always be in the right order. • When it got a slot event it would immediately change the slot number and then set the pending event. Then when it flushed the events it would use the new slot number to flush the old pending event so the events could have the wrong finger. The pending event is now immediately flushed when a slot event is received so it will have the right finger. • If you get more than 32 events in one read then it was resetting the pending events before processing the next batch in evdev_process_events. If four fingers were pressed down at once then it ended up with more than 32 events and the sync message would be in the second batch. The pending flag for the last finger was getting cleared so it never got emitted. In this patch the pending event is no longer reset after reading nor is it explicitly flushed. Instead it is flushed when we receive a EV_SYN event or a different pending event needs to replace it. The touchpad handling code was trying to use the pending event mechanism to notify the relative motion events. I'm not sure why it was doing this because it looks the event would effectively get emitted as soon as the touchpad_process function is finished anyway and it wasn't accumulating the values. Instead I've just changed it to emit the event directly. https://bugs.freedesktop.org/show_bug.cgi?id=67563
2013-09-24 12:09:03 +01:00
EVDEV_ABSOLUTE_MOTION,
EVDEV_ABSOLUTE_TOUCH_UP,
evdev: Only track one pending event Instead of having a mask of pending events there is now an enum with a single value to represent the one pending event. The event gets flushed explicitly as part of the handling code for each event type rather than in the outer event reading loop. The pending event is used so that we can combine multiple motion events into one and to make sure that we have recieved the latest position before sending a touch up or down event. This should fix the following problems with the old approach: • If you release a finger and press it down again quickly you could get the up and down events in the same batch. However the pending events were always processed in the order down then up so it would end up notifying two down events and then an up. The pending event is now always flushed when there is a new up or down event so they will always be in the right order. • When it got a slot event it would immediately change the slot number and then set the pending event. Then when it flushed the events it would use the new slot number to flush the old pending event so the events could have the wrong finger. The pending event is now immediately flushed when a slot event is received so it will have the right finger. • If you get more than 32 events in one read then it was resetting the pending events before processing the next batch in evdev_process_events. If four fingers were pressed down at once then it ended up with more than 32 events and the sync message would be in the second batch. The pending flag for the last finger was getting cleared so it never got emitted. In this patch the pending event is no longer reset after reading nor is it explicitly flushed. Instead it is flushed when we receive a EV_SYN event or a different pending event needs to replace it. The touchpad handling code was trying to use the pending event mechanism to notify the relative motion events. I'm not sure why it was doing this because it looks the event would effectively get emitted as soon as the touchpad_process function is finished anyway and it wasn't accumulating the values. Instead I've just changed it to emit the event directly. https://bugs.freedesktop.org/show_bug.cgi?id=67563
2013-09-24 12:09:03 +01:00
EVDEV_ABSOLUTE_MT_DOWN,
EVDEV_ABSOLUTE_MT_MOTION,
EVDEV_ABSOLUTE_MT_UP,
EVDEV_RELATIVE_MOTION,
};
enum evdev_device_seat_capability {
EVDEV_DEVICE_POINTER = (1 << 0),
EVDEV_DEVICE_KEYBOARD = (1 << 1),
EVDEV_DEVICE_TOUCH = (1 << 2),
EVDEV_DEVICE_TABLET = (1 << 3),
EVDEV_DEVICE_TABLET_PAD = (1 << 4),
2015-01-22 16:41:50 +01:00
EVDEV_DEVICE_GESTURE = (1 << 5),
};
enum evdev_device_tags {
EVDEV_TAG_EXTERNAL_MOUSE = (1 << 0),
EVDEV_TAG_INTERNAL_TOUCHPAD = (1 << 1),
EVDEV_TAG_EXTERNAL_TOUCHPAD = (1 << 2),
EVDEV_TAG_TRACKPOINT = (1 << 3),
EVDEV_TAG_KEYBOARD = (1 << 4),
};
enum evdev_middlebutton_state {
MIDDLEBUTTON_IDLE,
MIDDLEBUTTON_LEFT_DOWN,
MIDDLEBUTTON_RIGHT_DOWN,
MIDDLEBUTTON_MIDDLE,
MIDDLEBUTTON_LEFT_UP_PENDING,
MIDDLEBUTTON_RIGHT_UP_PENDING,
MIDDLEBUTTON_IGNORE_LR,
MIDDLEBUTTON_IGNORE_L,
MIDDLEBUTTON_IGNORE_R,
MIDDLEBUTTON_PASSTHROUGH,
};
enum evdev_middlebutton_event {
MIDDLEBUTTON_EVENT_L_DOWN,
MIDDLEBUTTON_EVENT_R_DOWN,
MIDDLEBUTTON_EVENT_OTHER,
MIDDLEBUTTON_EVENT_L_UP,
MIDDLEBUTTON_EVENT_R_UP,
MIDDLEBUTTON_EVENT_TIMEOUT,
MIDDLEBUTTON_EVENT_ALL_UP,
};
enum evdev_device_model {
EVDEV_MODEL_DEFAULT = 0,
EVDEV_MODEL_LENOVO_X230 = (1 << 0),
EVDEV_MODEL_CHROMEBOOK = (1 << 1),
EVDEV_MODEL_SYSTEM76_BONOBO = (1 << 2),
EVDEV_MODEL_SYSTEM76_GALAGO = (1 << 3),
EVDEV_MODEL_SYSTEM76_KUDU = (1 << 4),
EVDEV_MODEL_CLEVO_W740SU = (1 << 5),
EVDEV_MODEL_APPLE_TOUCHPAD = (1 << 6),
EVDEV_MODEL_WACOM_TOUCHPAD = (1 << 7),
EVDEV_MODEL_ALPS_TOUCHPAD = (1 << 8),
EVDEV_MODEL_SYNAPTICS_SERIAL_TOUCHPAD = (1 << 9),
EVDEV_MODEL_JUMPING_SEMI_MT = (1 << 10),
EVDEV_MODEL_ELANTECH_TOUCHPAD = (1 << 11),
EVDEV_MODEL_LENOVO_X220_TOUCHPAD_FW81 = (1 << 12),
EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD = (1 << 13),
EVDEV_MODEL_CYBORG_RAT = (1 << 14),
EVDEV_MODEL_CYAPA = (1 << 15),
EVDEV_MODEL_LENOVO_T450_TOUCHPAD= (1 << 17),
EVDEV_MODEL_DELL_TOUCHPAD = (1 << 18),
EVDEV_MODEL_TRACKBALL = (1 << 19),
EVDEV_MODEL_APPLE_MAGICMOUSE = (1 << 20),
};
struct mt_slot {
int32_t seat_slot;
struct device_coords point;
struct device_coords hysteresis_center;
};
struct evdev_device {
struct libinput_device base;
struct libinput_source *source;
struct evdev_dispatch *dispatch;
struct libevdev *evdev;
struct udev_device *udev_device;
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
char *output_name;
const char *devname;
bool was_removed;
int fd;
struct {
const struct input_absinfo *absinfo_x, *absinfo_y;
int fake_resolution;
struct device_coords point;
int32_t seat_slot;
int apply_calibration;
struct matrix calibration;
struct matrix default_calibration; /* from LIBINPUT_CALIBRATION_MATRIX */
struct matrix usermatrix; /* as supplied by the caller */
struct device_coords dimensions;
} abs;
struct mtdev *mtdev;
struct device_coords rel;
struct {
struct libinput_timer timer;
struct libinput_device_config_scroll_method config;
/* Currently enabled method, button */
enum libinput_config_scroll_method method;
uint32_t button;
uint64_t button_down_time;
/* set during device init, used at runtime to delay changes
* until all buttons are up */
enum libinput_config_scroll_method want_method;
uint32_t want_button;
/* Checks if buttons are down and commits the setting */
void (*change_scroll_method)(struct evdev_device *device);
bool button_scroll_active;
bool button_scroll_btn_pressed;
double threshold;
double direction_lock_threshold;
uint32_t direction;
struct normalized_coords buildup;
struct libinput_device_config_natural_scroll config_natural;
/* set during device init if we want natural scrolling,
* used at runtime to enable/disable the feature */
bool natural_scrolling_enabled;
/* angle per REL_WHEEL click in degrees */
int wheel_click_angle;
} scroll;
evdev: Only track one pending event Instead of having a mask of pending events there is now an enum with a single value to represent the one pending event. The event gets flushed explicitly as part of the handling code for each event type rather than in the outer event reading loop. The pending event is used so that we can combine multiple motion events into one and to make sure that we have recieved the latest position before sending a touch up or down event. This should fix the following problems with the old approach: • If you release a finger and press it down again quickly you could get the up and down events in the same batch. However the pending events were always processed in the order down then up so it would end up notifying two down events and then an up. The pending event is now always flushed when there is a new up or down event so they will always be in the right order. • When it got a slot event it would immediately change the slot number and then set the pending event. Then when it flushed the events it would use the new slot number to flush the old pending event so the events could have the wrong finger. The pending event is now immediately flushed when a slot event is received so it will have the right finger. • If you get more than 32 events in one read then it was resetting the pending events before processing the next batch in evdev_process_events. If four fingers were pressed down at once then it ended up with more than 32 events and the sync message would be in the second batch. The pending flag for the last finger was getting cleared so it never got emitted. In this patch the pending event is no longer reset after reading nor is it explicitly flushed. Instead it is flushed when we receive a EV_SYN event or a different pending event needs to replace it. The touchpad handling code was trying to use the pending event mechanism to notify the relative motion events. I'm not sure why it was doing this because it looks the event would effectively get emitted as soon as the touchpad_process function is finished anyway and it wasn't accumulating the values. Instead I've just changed it to emit the event directly. https://bugs.freedesktop.org/show_bug.cgi?id=67563
2013-09-24 12:09:03 +01:00
enum evdev_event_type pending_event;
enum evdev_device_seat_capability seat_caps;
enum evdev_device_tags tags;
int is_mt;
int suspended;
struct {
struct libinput_device_config_accel config;
struct motion_filter *filter;
} pointer;
/* Bitmask of pressed keys used to ignore initial release events from
* the kernel. */
unsigned long hw_key_mask[NLONGS(KEY_CNT)];
/* Key counter used for multiplexing button events internally in
* libinput. */
uint8_t key_count[KEY_CNT];
struct {
struct libinput_device_config_left_handed config;
/* left-handed currently enabled */
bool enabled;
/* set during device init if we want left_handed config,
* used at runtime to delay the effect until buttons are up */
bool want_enabled;
/* Checks if buttons are down and commits the setting */
void (*change_to_enabled)(struct evdev_device *device);
} left_handed;
struct {
struct libinput_device_config_middle_emulation config;
/* middle-button emulation enabled */
bool enabled;
bool enabled_default;
bool want_enabled;
enum evdev_middlebutton_state state;
struct libinput_timer timer;
uint32_t button_mask;
uint64_t first_event_time;
} middlebutton;
int dpi; /* HW resolution */
struct ratelimit syn_drop_limit; /* ratelimit for SYN_DROPPED logging */
struct ratelimit nonpointer_rel_limit; /* ratelimit for REL_* events from non-pointer devices */
uint32_t model_flags;
};
#define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
struct evdev_dispatch;
struct evdev_dispatch_interface {
/* Process an evdev input event. */
void (*process)(struct evdev_dispatch *dispatch,
struct evdev_device *device,
struct input_event *event,
uint64_t time);
/* Device is being suspended */
void (*suspend)(struct evdev_dispatch *dispatch,
struct evdev_device *device);
/* Device is being removed (may be NULL) */
void (*remove)(struct evdev_dispatch *dispatch);
/* Destroy an event dispatch handler and free all its resources. */
void (*destroy)(struct evdev_dispatch *dispatch);
/* A new device was added */
void (*device_added)(struct evdev_device *device,
struct evdev_device *added_device);
/* A device was removed */
void (*device_removed)(struct evdev_device *device,
struct evdev_device *removed_device);
/* A device was suspended */
void (*device_suspended)(struct evdev_device *device,
struct evdev_device *suspended_device);
/* A device was resumed */
void (*device_resumed)(struct evdev_device *device,
struct evdev_device *resumed_device);
/* Called immediately after the LIBINPUT_EVENT_DEVICE_ADDED event
* was sent */
void (*post_added)(struct evdev_device *device,
struct evdev_dispatch *dispatch);
};
struct evdev_dispatch {
struct evdev_dispatch_interface *interface;
struct libinput_device_config_calibration calibration;
struct {
bool is_enabled;
int angle;
struct matrix matrix;
struct libinput_device_config_rotation config;
} rotation;
struct {
struct libinput_device_config_send_events config;
enum libinput_config_send_events_mode current_mode;
} sendevents;
struct {
int slot;
struct mt_slot *slots;
size_t slots_len;
bool want_hysteresis;
struct device_coords hysteresis_margin;
} mt;
};
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
struct evdev_device *
evdev_device_create(struct libinput_seat *seat,
struct udev_device *device);
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
void
evdev_transform_absolute(struct evdev_device *device,
struct device_coords *point);
void
evdev_transform_relative(struct evdev_device *device,
struct device_coords *point);
void
evdev_init_calibration(struct evdev_device *device,
struct evdev_dispatch *dispatch);
void
evdev_device_init_pointer_acceleration(struct evdev_device *device,
struct motion_filter *filter);
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
struct evdev_dispatch *
evdev_touchpad_create(struct evdev_device *device);
struct evdev_dispatch *
evdev_mt_touchpad_create(struct evdev_device *device);
struct evdev_dispatch *
evdev_tablet_create(struct evdev_device *device);
struct evdev_dispatch *
evdev_tablet_pad_create(struct evdev_device *device);
void
evdev_device_led_update(struct evdev_device *device, enum libinput_led leds);
int
evdev_device_get_keys(struct evdev_device *device, char *keys, size_t size);
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
const char *
evdev_device_get_output(struct evdev_device *device);
const char *
evdev_device_get_sysname(struct evdev_device *device);
const char *
evdev_device_get_name(struct evdev_device *device);
unsigned int
evdev_device_get_id_product(struct evdev_device *device);
unsigned int
evdev_device_get_id_vendor(struct evdev_device *device);
struct udev_device *
evdev_device_get_udev_device(struct evdev_device *device);
void
evdev_device_set_default_calibration(struct evdev_device *device,
const float calibration[6]);
void
evdev_device_calibrate(struct evdev_device *device,
const float calibration[6]);
bool
evdev_device_has_capability(struct evdev_device *device,
enum libinput_device_capability capability);
int
evdev_device_get_size(const struct evdev_device *device,
double *w,
double *h);
int
evdev_device_has_button(struct evdev_device *device, uint32_t code);
int
evdev_device_has_key(struct evdev_device *device, uint32_t code);
int
evdev_device_tablet_pad_get_num_buttons(struct evdev_device *device);
int
evdev_device_tablet_pad_get_num_rings(struct evdev_device *device);
int
evdev_device_tablet_pad_get_num_strips(struct evdev_device *device);
int
evdev_device_tablet_pad_get_num_mode_groups(struct evdev_device *device);
struct libinput_tablet_pad_mode_group *
evdev_device_tablet_pad_get_mode_group(struct evdev_device *device,
unsigned int index);
unsigned int
evdev_device_tablet_pad_mode_group_get_button_target(
struct libinput_tablet_pad_mode_group *g,
unsigned int button_index);
struct libinput_tablet_pad_led *
evdev_device_tablet_pad_get_led(struct evdev_device *device,
unsigned int led);
double
evdev_device_transform_x(struct evdev_device *device,
double x,
uint32_t width);
double
evdev_device_transform_y(struct evdev_device *device,
double y,
uint32_t height);
void
evdev_device_suspend(struct evdev_device *device);
int
evdev_device_resume(struct evdev_device *device);
void
evdev_notify_suspended_device(struct evdev_device *device);
void
evdev_notify_resumed_device(struct evdev_device *device);
void
evdev_keyboard_notify_key(struct evdev_device *device,
uint64_t time,
int key,
enum libinput_key_state state);
void
evdev_pointer_notify_button(struct evdev_device *device,
uint64_t time,
unsigned int button,
enum libinput_button_state state);
void
evdev_pointer_notify_physical_button(struct evdev_device *device,
uint64_t time,
int button,
enum libinput_button_state state);
void
evdev_init_natural_scroll(struct evdev_device *device);
void
evdev_notify_axis(struct evdev_device *device,
uint64_t time,
uint32_t axes,
enum libinput_pointer_axis_source source,
const struct normalized_coords *delta_in,
const struct discrete_coords *discrete_in);
void
evdev_post_scroll(struct evdev_device *device,
uint64_t time,
Add pointer axis sources to the API 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>
2014-11-05 16:22:07 +10:00
enum libinput_pointer_axis_source source,
const struct normalized_coords *delta);
void
Add pointer axis sources to the API 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>
2014-11-05 16:22:07 +10:00
evdev_stop_scroll(struct evdev_device *device,
uint64_t time,
enum libinput_pointer_axis_source source);
void
Port udev-seat to be used in libinput This patch ports udev-seat from weston to libinput, including adapting libinput internals and API to provide seat and device discovery. The public API is extended with device discovery, object reference, a seat object. As libinput takes care of creating and destroying its objects user data getter/setter is added in order to make it possible for the client to directly associate an object application side with an object library side. Device discovery API is made up of the 'seat added', 'seat removed', 'device added' and 'device removed' events. The seat added/removed events contains a pointer to a libinput_seat struct, while the device added/removed events contains a pointer to a libinput_device event. The objects are reference counted with libinput holding one reference by default. The application can increase the reference count with libinput_seat_ref() and libinput_device_ref() and decrease the reference count with libinput_seat_unref() and libinput_device_unref(). The basic event struct is changed to have a 'target' union parameter that can be either a libinput, libinput_seat or libinput_device struct pointer. There is one known problem with the current API that is the potentially racy initialization. The problem is when a device is both discovered and lost during initial dispatchig, causing libinput to first queue a 'added' message, creating the device with default reference count 1, then before going back to the application queuing a 'removed' message, while at same time decreasing reference count of the device to 0, causing it o be destroyed. The queue will at this state contain two messages with pointers to free:ed memory. Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
2013-11-23 13:04:32 +01:00
evdev_device_remove(struct evdev_device *device);
void
evdev_device_destroy(struct evdev_device *device);
bool
evdev_middlebutton_filter_button(struct evdev_device *device,
uint64_t time,
int button,
enum libinput_button_state state);
void
evdev_init_middlebutton(struct evdev_device *device,
bool enabled,
bool want_config);
enum libinput_config_middle_emulation_state
evdev_middlebutton_get(struct libinput_device *device);
int
evdev_middlebutton_is_available(struct libinput_device *device);
enum libinput_config_middle_emulation_state
evdev_middlebutton_get_default(struct libinput_device *device);
static inline double
evdev_convert_to_mm(const struct input_absinfo *absinfo, double v)
{
double value = v - absinfo->minimum;
return value/absinfo->resolution;
}
void
evdev_init_left_handed(struct evdev_device *device,
void (*change_to_left_handed)(struct evdev_device *));
bool
evdev_tablet_has_left_handed(struct evdev_device *device);
static inline uint32_t
evdev_to_left_handed(struct evdev_device *device,
uint32_t button)
{
if (device->left_handed.enabled) {
if (button == BTN_LEFT)
return BTN_RIGHT;
else if (button == BTN_RIGHT)
return BTN_LEFT;
}
return button;
}
static inline int
evdev_hysteresis(int in, int center, int margin)
{
int diff = in - center;
if (abs(diff) <= margin)
return center;
if (diff > margin)
return center + diff - margin;
else
return center + diff + margin;
}
static inline struct libinput *
evdev_libinput_context(const struct evdev_device *device)
{
return device->base.seat->libinput;
}
/**
* Convert the pair of coordinates in device space to mm. This takes the
* axis min into account, i.e. a unit of min is equivalent to 0 mm.
*/
static inline struct phys_coords
evdev_device_units_to_mm(const struct evdev_device* device,
const struct device_coords *units)
{
struct phys_coords mm = { 0, 0 };
const struct input_absinfo *absx, *absy;
if (device->abs.absinfo_x == NULL ||
device->abs.absinfo_y == NULL) {
log_bug_libinput(evdev_libinput_context(device),
"%s: is not an abs device\n",
device->devname);
return mm;
}
absx = device->abs.absinfo_x;
absy = device->abs.absinfo_y;
mm.x = (units->x - absx->minimum)/absx->resolution;
mm.y = (units->y - absy->minimum)/absy->resolution;
return mm;
}
/**
* Convert the pair of coordinates in mm to device units. This takes the
* axis min into account, i.e. 0 mm is equivalent to the min.
*/
static inline struct device_coords
evdev_device_mm_to_units(const struct evdev_device *device,
const struct phys_coords *mm)
{
struct device_coords units = { 0, 0 };
const struct input_absinfo *absx, *absy;
if (device->abs.absinfo_x == NULL ||
device->abs.absinfo_y == NULL) {
log_bug_libinput(evdev_libinput_context(device),
"%s: is not an abs device\n",
device->devname);
return units;
}
absx = device->abs.absinfo_x;
absy = device->abs.absinfo_y;
units.x = mm->x * absx->resolution + absx->minimum;
units.y = mm->y * absy->resolution + absy->minimum;
return units;
}
#endif /* EVDEV_H */