2012-05-17 12:18:17 +02:00
|
|
|
/*
|
2015-05-06 13:14:23 +10:00
|
|
|
* Copyright © 2006-2009 Simon Thum
|
2012-05-17 12:18:17 +02:00
|
|
|
* Copyright © 2012 Jonas Ådahl
|
2015-05-28 08:23:59 +10:00
|
|
|
* Copyright © 2014-2015 Red Hat, Inc.
|
2012-05-17 12:18:17 +02:00
|
|
|
*
|
2015-06-11 12:09:18 +10:00
|
|
|
* 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:
|
2012-05-17 12:18:17 +02:00
|
|
|
*
|
2015-06-11 12:09:18 +10:00
|
|
|
* 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.
|
2012-05-17 12:18:17 +02:00
|
|
|
*/
|
|
|
|
|
|
2013-05-22 18:03:19 +03:00
|
|
|
#include "config.h"
|
|
|
|
|
|
2014-07-03 15:53:56 +10:00
|
|
|
#include <assert.h>
|
2014-05-18 19:20:39 +02:00
|
|
|
#include <stdio.h>
|
2012-05-17 12:18:17 +02:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <limits.h>
|
|
|
|
|
#include <math.h>
|
|
|
|
|
|
|
|
|
|
#include "filter.h"
|
2014-07-14 16:19:33 +10:00
|
|
|
#include "libinput-util.h"
|
2014-07-04 09:29:11 +10:00
|
|
|
#include "filter-private.h"
|
2012-05-17 12:18:17 +02:00
|
|
|
|
2015-08-18 09:11:48 +10:00
|
|
|
/* Once normalized, touchpads see the same acceleration as mice. that is
|
|
|
|
|
* technically correct but subjectively wrong, we expect a touchpad to be a
|
|
|
|
|
* lot slower than a mouse. Apply a magic factor to slow down all movements
|
|
|
|
|
*/
|
2016-12-14 19:51:13 +10:00
|
|
|
#define TP_MAGIC_SLOWDOWN 0.37 /* unitless factor */
|
2015-08-18 09:11:48 +10:00
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
/* Convert speed/velocity from units/us to units/ms */
|
|
|
|
|
static inline double
|
|
|
|
|
v_us2ms(double units_per_us)
|
|
|
|
|
{
|
|
|
|
|
return units_per_us * 1000.0;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-15 14:15:22 +10:00
|
|
|
static inline double
|
|
|
|
|
v_us2s(double units_per_us)
|
|
|
|
|
{
|
|
|
|
|
return units_per_us * 1000000.0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
/* Convert speed/velocity from units/ms to units/us */
|
|
|
|
|
static inline double
|
|
|
|
|
v_ms2us(double units_per_ms)
|
|
|
|
|
{
|
|
|
|
|
return units_per_ms/1000.0;
|
|
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
static inline struct normalized_coords
|
|
|
|
|
normalize_for_dpi(const struct device_float_coords *coords, int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct normalized_coords norm;
|
|
|
|
|
|
|
|
|
|
norm.x = coords->x * DEFAULT_MOUSE_DPI/dpi;
|
|
|
|
|
norm.y = coords->y * DEFAULT_MOUSE_DPI/dpi;
|
|
|
|
|
|
|
|
|
|
return norm;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-19 11:02:51 +10:00
|
|
|
struct normalized_coords
|
2013-11-10 17:55:40 +01:00
|
|
|
filter_dispatch(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2014-04-08 12:29:45 +02:00
|
|
|
void *data, uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
2015-03-19 11:02:51 +10:00
|
|
|
return filter->interface->filter(filter, unaccelerated, data, time);
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
2015-08-17 16:32:20 +10:00
|
|
|
struct normalized_coords
|
|
|
|
|
filter_dispatch_constant(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-08-17 16:32:20 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
return filter->interface->filter_constant(filter, unaccelerated, data, time);
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-10 09:54:06 +10:00
|
|
|
void
|
|
|
|
|
filter_restart(struct motion_filter *filter,
|
|
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
2015-08-27 13:13:47 +10:00
|
|
|
if (filter->interface->restart)
|
|
|
|
|
filter->interface->restart(filter, data, time);
|
2015-06-10 09:54:06 +10:00
|
|
|
}
|
|
|
|
|
|
2014-07-04 09:39:05 +10:00
|
|
|
void
|
|
|
|
|
filter_destroy(struct motion_filter *filter)
|
|
|
|
|
{
|
2015-08-27 13:13:47 +10:00
|
|
|
if (!filter || !filter->interface->destroy)
|
2014-07-04 09:39:05 +10:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
filter->interface->destroy(filter);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-03 15:53:56 +10:00
|
|
|
bool
|
|
|
|
|
filter_set_speed(struct motion_filter *filter,
|
2015-08-04 15:48:40 +10:00
|
|
|
double speed_adjustment)
|
2014-07-03 15:53:56 +10:00
|
|
|
{
|
2015-08-04 15:48:40 +10:00
|
|
|
return filter->interface->set_speed(filter, speed_adjustment);
|
2014-07-03 15:53:56 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
double
|
|
|
|
|
filter_get_speed(struct motion_filter *filter)
|
|
|
|
|
{
|
2015-08-04 15:48:40 +10:00
|
|
|
return filter->speed_adjustment;
|
2014-07-03 15:53:56 +10:00
|
|
|
}
|
|
|
|
|
|
2015-08-27 13:13:47 +10:00
|
|
|
enum libinput_config_accel_profile
|
|
|
|
|
filter_get_type(struct motion_filter *filter)
|
|
|
|
|
{
|
|
|
|
|
return filter->interface->type;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-17 12:18:17 +02:00
|
|
|
/*
|
2014-05-18 19:20:39 +02:00
|
|
|
* Default parameters for pointer acceleration profiles.
|
|
|
|
|
*/
|
|
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
#define DEFAULT_THRESHOLD v_ms2us(0.4) /* in units/us */
|
|
|
|
|
#define MINIMUM_THRESHOLD v_ms2us(0.2) /* in units/us */
|
2014-07-08 11:45:36 +10:00
|
|
|
#define DEFAULT_ACCELERATION 2.0 /* unitless factor */
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
#define DEFAULT_INCLINE 1.1 /* unitless factor */
|
2014-05-18 19:20:39 +02:00
|
|
|
|
2016-11-14 16:47:26 +10:00
|
|
|
/* Touchpad acceleration */
|
2016-12-14 19:40:18 +10:00
|
|
|
#define TOUCHPAD_DEFAULT_THRESHOLD 254 /* mm/s */
|
|
|
|
|
#define TOUCHPAD_THRESHOLD_RANGE 184 /* mm/s */
|
|
|
|
|
#define TOUCHPAD_ACCELERATION 9.0 /* unitless factor */
|
2016-12-15 16:23:57 +10:00
|
|
|
#define TOUCHPAD_INCLINE 0.011 /* unitless factor */
|
2016-11-14 16:47:26 +10:00
|
|
|
|
2015-07-28 15:53:23 +10:00
|
|
|
/* for the Lenovo x230 custom accel. do not touch */
|
|
|
|
|
#define X230_THRESHOLD v_ms2us(0.4) /* in units/us */
|
|
|
|
|
#define X230_ACCELERATION 2.0 /* unitless factor */
|
|
|
|
|
#define X230_INCLINE 1.1 /* unitless factor */
|
2015-08-31 14:05:11 +10:00
|
|
|
#define X230_MAGIC_SLOWDOWN 0.4 /* unitless */
|
|
|
|
|
#define X230_TP_MAGIC_LOW_RES_FACTOR 4.0 /* unitless */
|
2015-07-28 15:53:23 +10:00
|
|
|
|
2014-05-18 19:20:39 +02:00
|
|
|
/*
|
|
|
|
|
* Pointer acceleration filter constants
|
2012-05-17 12:18:17 +02:00
|
|
|
*/
|
|
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
#define MAX_VELOCITY_DIFF v_ms2us(1) /* units/us */
|
2015-07-27 17:51:52 +08:00
|
|
|
#define MOTION_TIMEOUT ms2us(1000)
|
2012-05-17 12:18:17 +02:00
|
|
|
#define NUM_POINTER_TRACKERS 16
|
|
|
|
|
|
|
|
|
|
struct pointer_tracker {
|
2017-01-18 17:22:30 +10:00
|
|
|
struct device_float_coords delta; /* delta to most recent event */
|
2015-07-27 17:51:52 +08:00
|
|
|
uint64_t time; /* us */
|
2016-12-15 12:16:28 +10:00
|
|
|
uint32_t dir;
|
2012-05-17 12:18:17 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct pointer_accelerator {
|
2013-11-10 17:55:40 +01:00
|
|
|
struct motion_filter base;
|
2012-05-17 12:18:17 +02:00
|
|
|
|
|
|
|
|
accel_profile_func_t profile;
|
|
|
|
|
|
2015-08-04 15:45:53 +10:00
|
|
|
double velocity; /* units/us */
|
|
|
|
|
double last_velocity; /* units/us */
|
2012-05-17 12:18:17 +02:00
|
|
|
|
|
|
|
|
struct pointer_tracker *trackers;
|
|
|
|
|
int cur_tracker;
|
2014-07-03 15:32:40 +10:00
|
|
|
|
2015-08-04 15:45:53 +10:00
|
|
|
double threshold; /* units/us */
|
2014-07-03 15:32:40 +10:00
|
|
|
double accel; /* unitless factor */
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
double incline; /* incline of the function */
|
2015-06-19 16:03:42 +10:00
|
|
|
|
2016-12-15 09:22:23 +10:00
|
|
|
int dpi;
|
2012-05-17 12:18:17 +02:00
|
|
|
};
|
|
|
|
|
|
2015-08-27 13:13:47 +10:00
|
|
|
struct pointer_accelerator_flat {
|
|
|
|
|
struct motion_filter base;
|
|
|
|
|
|
|
|
|
|
double factor;
|
2016-12-15 09:22:23 +10:00
|
|
|
int dpi;
|
2015-08-27 13:13:47 +10:00
|
|
|
};
|
|
|
|
|
|
2016-01-06 15:26:49 +10:00
|
|
|
struct tablet_accelerator_flat {
|
|
|
|
|
struct motion_filter base;
|
|
|
|
|
|
|
|
|
|
double factor;
|
|
|
|
|
int xres, yres;
|
2016-06-21 15:20:08 +10:00
|
|
|
double xres_scale, /* 1000dpi : tablet res */
|
|
|
|
|
yres_scale; /* 1000dpi : tablet res */
|
2016-01-06 15:26:49 +10:00
|
|
|
};
|
|
|
|
|
|
2012-05-17 12:18:17 +02:00
|
|
|
static void
|
|
|
|
|
feed_trackers(struct pointer_accelerator *accel,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *delta,
|
2014-04-08 12:29:45 +02:00
|
|
|
uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
int i, current;
|
|
|
|
|
struct pointer_tracker *trackers = accel->trackers;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < NUM_POINTER_TRACKERS; i++) {
|
2015-03-19 11:02:51 +10:00
|
|
|
trackers[i].delta.x += delta->x;
|
|
|
|
|
trackers[i].delta.y += delta->y;
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
current = (accel->cur_tracker + 1) % NUM_POINTER_TRACKERS;
|
|
|
|
|
accel->cur_tracker = current;
|
|
|
|
|
|
2015-03-19 11:02:51 +10:00
|
|
|
trackers[current].delta.x = 0.0;
|
|
|
|
|
trackers[current].delta.y = 0.0;
|
2012-05-17 12:18:17 +02:00
|
|
|
trackers[current].time = time;
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
trackers[current].dir = device_float_get_direction(*delta);
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct pointer_tracker *
|
|
|
|
|
tracker_by_offset(struct pointer_accelerator *accel, unsigned int offset)
|
|
|
|
|
{
|
|
|
|
|
unsigned int index =
|
|
|
|
|
(accel->cur_tracker + NUM_POINTER_TRACKERS - offset)
|
|
|
|
|
% NUM_POINTER_TRACKERS;
|
|
|
|
|
return &accel->trackers[index];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static double
|
2014-04-08 12:29:45 +02:00
|
|
|
calculate_tracker_velocity(struct pointer_tracker *tracker, uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
2015-03-19 11:33:55 +10:00
|
|
|
double tdelta = time - tracker->time + 1;
|
2017-01-18 17:22:30 +10:00
|
|
|
return hypot(tracker->delta.x, tracker->delta.y) / tdelta; /* units/us */
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
2015-04-22 12:25:13 +10:00
|
|
|
static inline double
|
|
|
|
|
calculate_velocity_after_timeout(struct pointer_tracker *tracker)
|
|
|
|
|
{
|
|
|
|
|
/* First movement after timeout needs special handling.
|
|
|
|
|
*
|
|
|
|
|
* When we trigger the timeout, the last event is too far in the
|
|
|
|
|
* past to use it for velocity calculation across multiple tracker
|
|
|
|
|
* values.
|
|
|
|
|
*
|
|
|
|
|
* Use the motion timeout itself to calculate the speed rather than
|
|
|
|
|
* the last tracker time. This errs on the side of being too fast
|
|
|
|
|
* for really slow movements but provides much more useful initial
|
|
|
|
|
* movement in normal use-cases (pause, move, pause, move)
|
|
|
|
|
*/
|
|
|
|
|
return calculate_tracker_velocity(tracker,
|
|
|
|
|
tracker->time + MOTION_TIMEOUT);
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-13 15:31:27 +10:00
|
|
|
/**
|
|
|
|
|
* Calculate the velocity based on the tracker data. Velocity is averaged
|
|
|
|
|
* across multiple historical values, provided those values aren't "too
|
|
|
|
|
* different" to our current one. That includes either being too far in the
|
|
|
|
|
* past, moving into a different direction or having too much of a velocity
|
|
|
|
|
* change between events.
|
|
|
|
|
*/
|
2012-05-17 12:18:17 +02:00
|
|
|
static double
|
2014-04-08 12:29:45 +02:00
|
|
|
calculate_velocity(struct pointer_accelerator *accel, uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
struct pointer_tracker *tracker;
|
|
|
|
|
double velocity;
|
|
|
|
|
double result = 0.0;
|
2014-05-24 21:49:13 +02:00
|
|
|
double initial_velocity = 0.0;
|
2012-05-17 12:18:17 +02:00
|
|
|
double velocity_diff;
|
|
|
|
|
unsigned int offset;
|
|
|
|
|
|
|
|
|
|
unsigned int dir = tracker_by_offset(accel, 0)->dir;
|
|
|
|
|
|
|
|
|
|
/* Find least recent vector within a timelimit, maximum velocity diff
|
|
|
|
|
* and direction threshold. */
|
2014-05-24 21:49:13 +02:00
|
|
|
for (offset = 1; offset < NUM_POINTER_TRACKERS; offset++) {
|
2012-05-17 12:18:17 +02:00
|
|
|
tracker = tracker_by_offset(accel, offset);
|
|
|
|
|
|
2016-12-13 15:28:29 +10:00
|
|
|
/* Bug: time running backwards */
|
|
|
|
|
if (tracker->time > time)
|
|
|
|
|
break;
|
|
|
|
|
|
2012-05-17 12:18:17 +02:00
|
|
|
/* Stop if too far away in time */
|
2016-12-13 15:28:29 +10:00
|
|
|
if (time - tracker->time > MOTION_TIMEOUT) {
|
2015-04-22 12:25:13 +10:00
|
|
|
if (offset == 1)
|
|
|
|
|
result = calculate_velocity_after_timeout(tracker);
|
2012-05-17 12:18:17 +02:00
|
|
|
break;
|
2015-04-22 12:25:13 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
velocity = calculate_tracker_velocity(tracker, time);
|
2012-05-17 12:18:17 +02:00
|
|
|
|
|
|
|
|
/* Stop if direction changed */
|
|
|
|
|
dir &= tracker->dir;
|
2015-04-22 12:25:13 +10:00
|
|
|
if (dir == 0) {
|
|
|
|
|
/* First movement after dirchange - velocity is that
|
|
|
|
|
* of the last movement */
|
|
|
|
|
if (offset == 1)
|
|
|
|
|
result = velocity;
|
2012-05-17 12:18:17 +02:00
|
|
|
break;
|
2015-04-22 12:25:13 +10:00
|
|
|
}
|
2012-05-17 12:18:17 +02:00
|
|
|
|
2014-05-24 21:49:13 +02:00
|
|
|
if (initial_velocity == 0.0) {
|
|
|
|
|
result = initial_velocity = velocity;
|
|
|
|
|
} else {
|
|
|
|
|
/* Stop if velocity differs too much from initial */
|
|
|
|
|
velocity_diff = fabs(initial_velocity - velocity);
|
|
|
|
|
if (velocity_diff > MAX_VELOCITY_DIFF)
|
|
|
|
|
break;
|
2012-05-17 12:18:17 +02:00
|
|
|
|
2014-05-24 21:49:13 +02:00
|
|
|
result = velocity;
|
|
|
|
|
}
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
2015-08-04 15:45:53 +10:00
|
|
|
return result; /* units/us */
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/**
|
|
|
|
|
* Apply the acceleration profile to the given velocity.
|
|
|
|
|
*
|
|
|
|
|
* @param accel The acceleration filter
|
|
|
|
|
* @param data Caller-specific data
|
|
|
|
|
* @param velocity Velocity in device-units per µs
|
|
|
|
|
* @param time Current time in µs
|
|
|
|
|
*
|
|
|
|
|
* @return A unitless acceleration factor, to be applied to the delta
|
|
|
|
|
*/
|
2012-05-17 12:18:17 +02:00
|
|
|
static double
|
|
|
|
|
acceleration_profile(struct pointer_accelerator *accel,
|
2014-04-08 12:29:45 +02:00
|
|
|
void *data, double velocity, uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
return accel->profile(&accel->base, data, velocity, time);
|
|
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/**
|
|
|
|
|
* Calculate the acceleration factor for our current velocity, averaging
|
|
|
|
|
* between our current and the most recent velocity to smoothen out changes.
|
|
|
|
|
*
|
|
|
|
|
* @param accel The acceleration filter
|
|
|
|
|
* @param data Caller-specific data
|
|
|
|
|
* @param velocity Velocity in device-units per µs
|
|
|
|
|
* @param last_velocity Previous velocity in device-units per µs
|
|
|
|
|
* @param time Current time in µs
|
|
|
|
|
*
|
|
|
|
|
* @return A unitless acceleration factor, to be applied to the delta
|
|
|
|
|
*/
|
2012-05-17 12:18:17 +02:00
|
|
|
static double
|
|
|
|
|
calculate_acceleration(struct pointer_accelerator *accel,
|
2015-04-30 15:23:34 +10:00
|
|
|
void *data,
|
|
|
|
|
double velocity,
|
|
|
|
|
double last_velocity,
|
|
|
|
|
uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
double factor;
|
|
|
|
|
|
|
|
|
|
/* Use Simpson's rule to calculate the avarage acceleration between
|
|
|
|
|
* the previous motion and the most recent. */
|
|
|
|
|
factor = acceleration_profile(accel, data, velocity, time);
|
2015-04-30 15:23:34 +10:00
|
|
|
factor += acceleration_profile(accel, data, last_velocity, time);
|
2012-05-17 12:18:17 +02:00
|
|
|
factor += 4.0 *
|
|
|
|
|
acceleration_profile(accel, data,
|
2015-04-30 15:23:34 +10:00
|
|
|
(last_velocity + velocity) / 2,
|
2012-05-17 12:18:17 +02:00
|
|
|
time);
|
|
|
|
|
|
|
|
|
|
factor = factor / 6.0;
|
|
|
|
|
|
2014-07-08 11:45:36 +10:00
|
|
|
return factor; /* unitless factor */
|
2012-05-17 12:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/**
|
|
|
|
|
* Calculate the acceleration factor for the given delta with the timestamp.
|
|
|
|
|
*
|
|
|
|
|
* @param accel The acceleration filter
|
|
|
|
|
* @param unaccelerated The raw delta in the device's dpi
|
|
|
|
|
* @param data Caller-specific data
|
|
|
|
|
* @param time Current time in µs
|
|
|
|
|
*
|
|
|
|
|
* @return A unitless acceleration factor, to be applied to the delta
|
|
|
|
|
*/
|
2015-07-28 15:46:33 +10:00
|
|
|
static inline double
|
|
|
|
|
calculate_acceleration_factor(struct pointer_accelerator *accel,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-07-28 15:46:33 +10:00
|
|
|
void *data,
|
|
|
|
|
uint64_t time)
|
|
|
|
|
{
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
double velocity; /* units/us in device-native dpi*/
|
2015-07-28 15:46:33 +10:00
|
|
|
double accel_factor;
|
|
|
|
|
|
|
|
|
|
feed_trackers(accel, unaccelerated, time);
|
|
|
|
|
velocity = calculate_velocity(accel, time);
|
|
|
|
|
accel_factor = calculate_acceleration(accel,
|
|
|
|
|
data,
|
|
|
|
|
velocity,
|
|
|
|
|
accel->last_velocity,
|
|
|
|
|
time);
|
|
|
|
|
accel->last_velocity = velocity;
|
|
|
|
|
|
|
|
|
|
return accel_factor;
|
|
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/**
|
|
|
|
|
* Generic filter that calculates the acceleration factor and applies it to
|
|
|
|
|
* the coordinates.
|
|
|
|
|
*
|
|
|
|
|
* @param filter The acceleration filter
|
|
|
|
|
* @param unaccelerated The raw delta in the device's dpi
|
|
|
|
|
* @param data Caller-specific data
|
|
|
|
|
* @param time Current time in µs
|
|
|
|
|
*
|
2017-01-18 17:58:36 +10:00
|
|
|
* @return An accelerated tuple of coordinates representing accelerated
|
|
|
|
|
* motion, still in device units.
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
*/
|
2017-01-18 17:58:36 +10:00
|
|
|
static struct device_float_coords
|
2016-12-15 11:26:52 +10:00
|
|
|
accelerator_filter_generic(struct motion_filter *filter,
|
|
|
|
|
const struct device_float_coords *unaccelerated,
|
|
|
|
|
void *data, uint64_t time)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
2014-07-08 11:45:36 +10:00
|
|
|
double accel_value; /* unitless factor */
|
2017-01-18 17:58:36 +10:00
|
|
|
struct device_float_coords accelerated;
|
2015-07-28 15:49:22 +10:00
|
|
|
|
|
|
|
|
accel_value = calculate_acceleration_factor(accel,
|
|
|
|
|
unaccelerated,
|
|
|
|
|
data,
|
|
|
|
|
time);
|
|
|
|
|
|
|
|
|
|
accelerated.x = accel_value * unaccelerated->x;
|
|
|
|
|
accelerated.y = accel_value * unaccelerated->y;
|
|
|
|
|
|
|
|
|
|
return accelerated;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-18 17:58:36 +10:00
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_post_normalized(struct motion_filter *filter,
|
|
|
|
|
const struct device_float_coords *unaccelerated,
|
|
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
struct device_float_coords accelerated;
|
|
|
|
|
|
|
|
|
|
/* Accelerate for device units, normalize afterwards */
|
|
|
|
|
accelerated = accelerator_filter_generic(filter,
|
|
|
|
|
unaccelerated,
|
|
|
|
|
data,
|
|
|
|
|
time);
|
|
|
|
|
return normalize_for_dpi(&accelerated, accel->dpi);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_pre_normalized(struct motion_filter *filter,
|
|
|
|
|
const struct device_float_coords *unaccelerated,
|
|
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
struct normalized_coords normalized;
|
|
|
|
|
struct device_float_coords converted, accelerated;
|
|
|
|
|
|
|
|
|
|
/* Accelerate for normalized units and return normalized units.
|
|
|
|
|
API requires device_floats, so we just copy the bits around */
|
|
|
|
|
normalized = normalize_for_dpi(unaccelerated, accel->dpi);
|
|
|
|
|
converted.x = normalized.x;
|
|
|
|
|
converted.y = normalized.y;
|
|
|
|
|
|
|
|
|
|
accelerated = accelerator_filter_generic(filter,
|
|
|
|
|
&converted,
|
|
|
|
|
data,
|
|
|
|
|
time);
|
|
|
|
|
normalized.x = accelerated.x;
|
|
|
|
|
normalized.y = accelerated.y;
|
|
|
|
|
return normalized;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_unnormalized(struct motion_filter *filter,
|
|
|
|
|
const struct device_float_coords *unaccelerated,
|
|
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct device_float_coords accelerated;
|
|
|
|
|
struct normalized_coords normalized;
|
|
|
|
|
|
|
|
|
|
/* Accelerate for device units and return device units */
|
|
|
|
|
accelerated = accelerator_filter_generic(filter,
|
|
|
|
|
unaccelerated,
|
|
|
|
|
data,
|
|
|
|
|
time);
|
|
|
|
|
normalized.x = accelerated.x;
|
|
|
|
|
normalized.y = accelerated.y;
|
|
|
|
|
return normalized;
|
|
|
|
|
}
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/**
|
|
|
|
|
* Generic filter that does nothing beyond converting from the device's
|
|
|
|
|
* native dpi into normalized coordinates.
|
|
|
|
|
*
|
|
|
|
|
* @param filter The acceleration filter
|
|
|
|
|
* @param unaccelerated The raw delta in the device's dpi
|
|
|
|
|
* @param data Caller-specific data
|
|
|
|
|
* @param time Current time in µs
|
|
|
|
|
*
|
|
|
|
|
* @return An accelerated tuple of coordinates representing normalized
|
|
|
|
|
* motion
|
|
|
|
|
*/
|
2015-08-17 16:32:20 +10:00
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_noop(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-08-17 16:32:20 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
|
|
|
|
|
return normalize_for_dpi(unaccelerated, accel->dpi);
|
2015-08-17 16:32:20 +10:00
|
|
|
}
|
|
|
|
|
|
2015-07-28 15:53:23 +10:00
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_x230(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *raw,
|
2015-07-28 15:53:23 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
double accel_factor; /* unitless factor */
|
|
|
|
|
struct normalized_coords accelerated;
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
struct device_float_coords delta_normalized;
|
|
|
|
|
struct normalized_coords unaccelerated;
|
2015-07-28 15:53:23 +10:00
|
|
|
double velocity; /* units/us */
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/* This filter is a "do not touch me" filter. So the hack here is
|
|
|
|
|
* just to replicate the old behavior before filters switched to
|
|
|
|
|
* device-native dpi:
|
|
|
|
|
* 1) convert from device-native to 1000dpi normalized
|
|
|
|
|
* 2) run all calculation on 1000dpi-normalized data
|
|
|
|
|
* 3) apply accel factor no normalized data
|
|
|
|
|
*/
|
|
|
|
|
unaccelerated = normalize_for_dpi(raw, accel->dpi);
|
|
|
|
|
delta_normalized.x = unaccelerated.x;
|
|
|
|
|
delta_normalized.y = unaccelerated.y;
|
|
|
|
|
|
|
|
|
|
feed_trackers(accel, &delta_normalized, time);
|
2015-07-28 15:53:23 +10:00
|
|
|
velocity = calculate_velocity(accel, time);
|
|
|
|
|
accel_factor = calculate_acceleration(accel,
|
|
|
|
|
data,
|
|
|
|
|
velocity,
|
|
|
|
|
accel->last_velocity,
|
|
|
|
|
time);
|
|
|
|
|
accel->last_velocity = velocity;
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
accelerated.x = accel_factor * delta_normalized.x;
|
|
|
|
|
accelerated.y = accel_factor * delta_normalized.y;
|
2015-07-28 15:53:23 +10:00
|
|
|
|
|
|
|
|
return accelerated;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-31 14:05:11 +10:00
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_constant_x230(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-08-31 14:05:11 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
2015-08-31 14:05:11 +10:00
|
|
|
struct normalized_coords normalized;
|
|
|
|
|
const double factor =
|
|
|
|
|
X230_MAGIC_SLOWDOWN/X230_TP_MAGIC_LOW_RES_FACTOR;
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
normalized = normalize_for_dpi(unaccelerated, accel->dpi);
|
|
|
|
|
normalized.x = factor * normalized.x;
|
|
|
|
|
normalized.y = factor * normalized.y;
|
2015-08-31 14:05:11 +10:00
|
|
|
|
|
|
|
|
return normalized;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-14 16:47:26 +10:00
|
|
|
static bool
|
|
|
|
|
touchpad_accelerator_set_speed(struct motion_filter *filter,
|
|
|
|
|
double speed_adjustment)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
|
|
|
|
|
assert(speed_adjustment >= -1.0 && speed_adjustment <= 1.0);
|
|
|
|
|
|
|
|
|
|
/* Note: the numbers below are nothing but trial-and-error magic,
|
|
|
|
|
don't read more into them other than "they mostly worked ok" */
|
|
|
|
|
|
2016-12-14 19:40:18 +10:00
|
|
|
/* adjust when accel kicks in */
|
2016-11-14 16:47:26 +10:00
|
|
|
accel_filter->threshold = TOUCHPAD_DEFAULT_THRESHOLD -
|
2016-12-14 19:40:18 +10:00
|
|
|
TOUCHPAD_THRESHOLD_RANGE * speed_adjustment;
|
|
|
|
|
accel_filter->accel = TOUCHPAD_ACCELERATION;
|
|
|
|
|
accel_filter->incline = TOUCHPAD_INCLINE;
|
2016-11-14 16:47:26 +10:00
|
|
|
filter->speed_adjustment = speed_adjustment;
|
2016-12-14 19:40:18 +10:00
|
|
|
|
2016-11-14 16:47:26 +10:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-06 14:59:38 +10:00
|
|
|
static struct normalized_coords
|
|
|
|
|
touchpad_constant_filter(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-08-06 14:59:38 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
2015-08-06 14:59:38 +10:00
|
|
|
struct normalized_coords normalized;
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
normalized = normalize_for_dpi(unaccelerated, accel->dpi);
|
|
|
|
|
normalized.x = TP_MAGIC_SLOWDOWN * normalized.x;
|
|
|
|
|
normalized.y = TP_MAGIC_SLOWDOWN * normalized.y;
|
2015-08-06 14:59:38 +10:00
|
|
|
|
|
|
|
|
return normalized;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-10 09:54:06 +10:00
|
|
|
static void
|
|
|
|
|
accelerator_restart(struct motion_filter *filter,
|
|
|
|
|
void *data,
|
|
|
|
|
uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
unsigned int offset;
|
|
|
|
|
struct pointer_tracker *tracker;
|
|
|
|
|
|
|
|
|
|
for (offset = 1; offset < NUM_POINTER_TRACKERS; offset++) {
|
|
|
|
|
tracker = tracker_by_offset(accel, offset);
|
|
|
|
|
tracker->time = 0;
|
|
|
|
|
tracker->dir = 0;
|
|
|
|
|
tracker->delta.x = 0;
|
|
|
|
|
tracker->delta.y = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tracker = tracker_by_offset(accel, 0);
|
|
|
|
|
tracker->time = time;
|
|
|
|
|
tracker->dir = UNDEFINED_DIRECTION;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-17 12:18:17 +02:00
|
|
|
static void
|
2013-11-10 17:55:40 +01:00
|
|
|
accelerator_destroy(struct motion_filter *filter)
|
2012-05-17 12:18:17 +02:00
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel =
|
|
|
|
|
(struct pointer_accelerator *) filter;
|
|
|
|
|
|
|
|
|
|
free(accel->trackers);
|
|
|
|
|
free(accel);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-03 15:53:56 +10:00
|
|
|
static bool
|
|
|
|
|
accelerator_set_speed(struct motion_filter *filter,
|
2015-08-04 15:48:40 +10:00
|
|
|
double speed_adjustment)
|
2014-07-03 15:53:56 +10:00
|
|
|
{
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
|
2015-08-04 15:48:40 +10:00
|
|
|
assert(speed_adjustment >= -1.0 && speed_adjustment <= 1.0);
|
2014-07-03 15:53:56 +10:00
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
/* Note: the numbers below are nothing but trial-and-error magic,
|
|
|
|
|
don't read more into them other than "they mostly worked ok" */
|
|
|
|
|
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
/* delay when accel kicks in */
|
2015-08-04 16:04:06 +10:00
|
|
|
accel_filter->threshold = DEFAULT_THRESHOLD -
|
|
|
|
|
v_ms2us(0.25) * speed_adjustment;
|
2015-08-04 15:08:25 +10:00
|
|
|
if (accel_filter->threshold < MINIMUM_THRESHOLD)
|
|
|
|
|
accel_filter->threshold = MINIMUM_THRESHOLD;
|
2014-07-03 15:53:56 +10:00
|
|
|
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
/* adjust max accel factor */
|
2015-08-04 15:48:40 +10:00
|
|
|
accel_filter->accel = DEFAULT_ACCELERATION + speed_adjustment * 1.5;
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
|
|
|
|
|
/* higher speed -> faster to reach max */
|
2015-08-04 15:48:40 +10:00
|
|
|
accel_filter->incline = DEFAULT_INCLINE + speed_adjustment * 0.75;
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
|
2015-08-04 15:48:40 +10:00
|
|
|
filter->speed_adjustment = speed_adjustment;
|
2014-07-03 15:53:56 +10:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-23 12:45:16 +10:00
|
|
|
/**
|
|
|
|
|
* Custom acceleration function for mice < 1000dpi.
|
|
|
|
|
* At slow motion, a single device unit causes a one-pixel movement.
|
|
|
|
|
* The threshold/max accel depends on the DPI, the smaller the DPI the
|
|
|
|
|
* earlier we accelerate and the higher the maximum acceleration is. Result:
|
|
|
|
|
* at low speeds we get pixel-precision, at high speeds we get approx. the
|
|
|
|
|
* same movement as a high-dpi mouse.
|
|
|
|
|
*
|
|
|
|
|
* Note: data fed to this function is in device units, not normalized.
|
|
|
|
|
*/
|
|
|
|
|
double
|
|
|
|
|
pointer_accel_profile_linear_low_dpi(struct motion_filter *filter,
|
|
|
|
|
void *data,
|
2015-08-04 15:45:53 +10:00
|
|
|
double speed_in, /* in device units (units/us) */
|
|
|
|
|
uint64_t time)
|
2015-06-23 12:45:16 +10:00
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
|
|
|
|
|
double max_accel = accel_filter->accel; /* unitless factor */
|
2015-08-05 13:39:33 +10:00
|
|
|
double threshold = accel_filter->threshold; /* units/us */
|
2015-06-23 12:45:16 +10:00
|
|
|
const double incline = accel_filter->incline;
|
2016-12-15 10:51:16 +10:00
|
|
|
double dpi_factor = accel_filter->dpi/(double)DEFAULT_MOUSE_DPI;
|
2015-08-04 16:01:20 +10:00
|
|
|
double factor; /* unitless */
|
2015-06-23 12:45:16 +10:00
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
/* dpi_factor is always < 1.0, increase max_accel, reduce
|
|
|
|
|
the threshold so it kicks in earlier */
|
2015-06-23 12:45:16 +10:00
|
|
|
max_accel /= dpi_factor;
|
2015-08-05 13:39:33 +10:00
|
|
|
threshold *= dpi_factor;
|
2015-06-23 12:45:16 +10:00
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
/* see pointer_accel_profile_linear for a long description */
|
|
|
|
|
if (v_us2ms(speed_in) < 0.07)
|
|
|
|
|
factor = 10 * v_us2ms(speed_in) + 0.3;
|
|
|
|
|
else if (speed_in < threshold)
|
|
|
|
|
factor = 1;
|
|
|
|
|
else
|
|
|
|
|
factor = incline * v_us2ms(speed_in - threshold) + 1;
|
2015-06-23 12:45:16 +10:00
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
factor = min(max_accel, factor);
|
2015-06-23 12:45:16 +10:00
|
|
|
|
|
|
|
|
return factor;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-18 19:20:39 +02:00
|
|
|
double
|
2014-09-19 11:10:17 +10:00
|
|
|
pointer_accel_profile_linear(struct motion_filter *filter,
|
|
|
|
|
void *data,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
double speed_in, /* in device units (units/µs) */
|
2015-08-04 15:45:53 +10:00
|
|
|
uint64_t time)
|
2014-05-18 19:20:39 +02:00
|
|
|
{
|
2014-07-03 15:32:40 +10:00
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
const double max_accel = accel_filter->accel; /* unitless factor */
|
2015-08-04 15:45:53 +10:00
|
|
|
const double threshold = accel_filter->threshold; /* units/us */
|
filter: adjust acceleration curve depending on speed
The acceleration curve consists of four parts, in ascii-art like this:
_____________
/
____/
/
/
where the x axis is the speed, y is the acceleration factor.
The first plateau is at the acceleration factor 1 (i.e. unaccelerated
movement), the second plateau is at the max acceleration factor. The threshold
in the code defines where and how long the plateau is.
This patch adjusts the curve based on a [-1, 1] range. For anything below 0,
the plateau is longer (i.e. accel kicks in at a higher speed), the second
incline is flatter (i.e. accel kicks in slower) and the max accel factor is
lower (i.e. maximum speed is slower). For anything above 0, the inverse is
true, acceleration kicks in earlier, harder and is faster in general. So the
default/min/max curves overlaid look something like this:
________ max
| _______ default
| / _____ min
_|_/_/
/
/
Note that there's a limit to what ascii art can do...
Note that there are additional tweaks we can introduce later, such as
decreaseing the unaccelerated speed of the device (i.e. lowering the first
plateau).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-09-19 14:25:22 +10:00
|
|
|
const double incline = accel_filter->incline;
|
2015-08-04 16:01:20 +10:00
|
|
|
double factor; /* unitless */
|
2014-09-19 11:10:17 +10:00
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/* Normalize to 1000dpi, because the rest below relies on that */
|
|
|
|
|
speed_in = speed_in * DEFAULT_MOUSE_DPI/accel_filter->dpi;
|
|
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
/*
|
|
|
|
|
Our acceleration function calculates a factor to accelerate input
|
|
|
|
|
deltas with. The function is a double incline with a plateau,
|
|
|
|
|
with a rough shape like this:
|
|
|
|
|
|
|
|
|
|
accel
|
|
|
|
|
factor
|
|
|
|
|
^
|
|
|
|
|
| /
|
|
|
|
|
| _____/
|
|
|
|
|
| /
|
|
|
|
|
|/
|
|
|
|
|
+-------------> speed in
|
|
|
|
|
|
|
|
|
|
The two inclines are linear functions in the form
|
|
|
|
|
y = ax + b
|
|
|
|
|
where y is speed_out
|
|
|
|
|
x is speed_in
|
|
|
|
|
a is the incline of acceleration
|
|
|
|
|
b is minimum acceleration factor
|
|
|
|
|
|
|
|
|
|
for speeds up to 0.07 u/ms, we decelerate, down to 30% of input
|
|
|
|
|
speed.
|
|
|
|
|
hence 1 = a * 0.07 + 0.3
|
2016-12-15 16:30:15 +10:00
|
|
|
0.7 = a * 0.07 => a := 10
|
2015-08-05 13:39:33 +10:00
|
|
|
deceleration function is thus:
|
|
|
|
|
y = 10x + 0.3
|
|
|
|
|
|
|
|
|
|
Note:
|
|
|
|
|
* 0.07u/ms as threshold is a result of trial-and-error and
|
|
|
|
|
has no other intrinsic meaning.
|
|
|
|
|
* 0.3 is chosen simply because it is above the Nyquist frequency
|
|
|
|
|
for subpixel motion within a pixel.
|
|
|
|
|
*/
|
|
|
|
|
if (v_us2ms(speed_in) < 0.07) {
|
|
|
|
|
factor = 10 * v_us2ms(speed_in) + 0.3;
|
|
|
|
|
/* up to the threshold, we keep factor 1, i.e. 1:1 movement */
|
|
|
|
|
} else if (speed_in < threshold) {
|
|
|
|
|
factor = 1;
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
/* Acceleration function above the threshold:
|
|
|
|
|
y = ax' + b
|
|
|
|
|
where T is threshold
|
|
|
|
|
x is speed_in
|
|
|
|
|
x' is speed
|
|
|
|
|
and
|
|
|
|
|
y(T) == 1
|
|
|
|
|
hence 1 = ax' + 1
|
|
|
|
|
=> x' := (x - T)
|
|
|
|
|
*/
|
|
|
|
|
factor = incline * v_us2ms(speed_in - threshold) + 1;
|
|
|
|
|
}
|
2014-09-19 11:10:17 +10:00
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
/* Cap at the maximum acceleration factor */
|
|
|
|
|
factor = min(max_accel, factor);
|
2015-06-23 12:45:55 +10:00
|
|
|
|
|
|
|
|
return factor;
|
2014-05-18 19:20:39 +02:00
|
|
|
}
|
2015-03-13 13:56:14 +10:00
|
|
|
|
|
|
|
|
double
|
|
|
|
|
touchpad_accel_profile_linear(struct motion_filter *filter,
|
2016-11-14 16:47:26 +10:00
|
|
|
void *data,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
double speed_in, /* in device units/µs */
|
2016-11-14 16:47:26 +10:00
|
|
|
uint64_t time)
|
2015-03-13 13:56:14 +10:00
|
|
|
{
|
2016-11-14 16:47:26 +10:00
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
const double max_accel = accel_filter->accel; /* unitless factor */
|
|
|
|
|
const double threshold = accel_filter->threshold; /* units/us */
|
|
|
|
|
const double incline = accel_filter->incline;
|
2015-08-04 16:01:20 +10:00
|
|
|
double factor; /* unitless */
|
2015-03-13 13:56:14 +10:00
|
|
|
|
2016-12-15 14:15:22 +10:00
|
|
|
/* Convert to mm/s because that's something one can understand */
|
|
|
|
|
speed_in = v_us2s(speed_in) * 25.4/accel_filter->dpi;
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
|
2016-11-14 16:47:26 +10:00
|
|
|
/*
|
|
|
|
|
Our acceleration function calculates a factor to accelerate input
|
|
|
|
|
deltas with. The function is a double incline with a plateau,
|
|
|
|
|
with a rough shape like this:
|
|
|
|
|
|
|
|
|
|
accel
|
|
|
|
|
factor
|
|
|
|
|
^
|
|
|
|
|
| /
|
|
|
|
|
| _____/
|
|
|
|
|
| /
|
|
|
|
|
|/
|
|
|
|
|
+-------------> speed in
|
|
|
|
|
|
|
|
|
|
The two inclines are linear functions in the form
|
|
|
|
|
y = ax + b
|
|
|
|
|
where y is speed_out
|
|
|
|
|
x is speed_in
|
|
|
|
|
a is the incline of acceleration
|
|
|
|
|
b is minimum acceleration factor
|
|
|
|
|
|
2016-12-15 14:15:22 +10:00
|
|
|
for speeds up to the lower threshold, we decelerate, down to 30%
|
|
|
|
|
of input speed.
|
2016-12-15 16:23:57 +10:00
|
|
|
hence 1 = a * 7 + 0.3
|
|
|
|
|
0.7 = a * 7 => a := 0.1
|
2016-11-14 16:47:26 +10:00
|
|
|
deceleration function is thus:
|
2016-12-15 16:23:57 +10:00
|
|
|
y = 0.1x + 0.3
|
2016-11-14 16:47:26 +10:00
|
|
|
|
|
|
|
|
Note:
|
2016-12-15 14:15:22 +10:00
|
|
|
* The minimum threshold is a result of trial-and-error and
|
2016-11-14 16:47:26 +10:00
|
|
|
has no other intrinsic meaning.
|
|
|
|
|
* 0.3 is chosen simply because it is above the Nyquist frequency
|
|
|
|
|
for subpixel motion within a pixel.
|
|
|
|
|
*/
|
2016-12-15 16:23:57 +10:00
|
|
|
if (speed_in < 7.0) {
|
|
|
|
|
factor = 0.1 * speed_in + 0.3;
|
2016-11-14 16:47:26 +10:00
|
|
|
/* up to the threshold, we keep factor 1, i.e. 1:1 movement */
|
|
|
|
|
} else if (speed_in < threshold) {
|
|
|
|
|
factor = 1;
|
|
|
|
|
} else {
|
|
|
|
|
/* Acceleration function above the threshold:
|
|
|
|
|
y = ax' + b
|
|
|
|
|
where T is threshold
|
|
|
|
|
x is speed_in
|
|
|
|
|
x' is speed
|
|
|
|
|
and
|
|
|
|
|
y(T) == 1
|
|
|
|
|
hence 1 = ax' + 1
|
|
|
|
|
=> x' := (x - T)
|
|
|
|
|
*/
|
2016-12-15 14:15:22 +10:00
|
|
|
factor = incline * (speed_in - threshold) + 1;
|
2016-11-14 16:47:26 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Cap at the maximum acceleration factor */
|
|
|
|
|
factor = min(max_accel, factor);
|
2015-03-13 13:56:14 +10:00
|
|
|
|
2016-12-14 19:40:18 +10:00
|
|
|
/* Scale everything depending on the acceleration set */
|
|
|
|
|
factor *= 1 + 0.5 * filter->speed_adjustment;
|
|
|
|
|
|
2015-08-04 16:01:20 +10:00
|
|
|
return factor * TP_MAGIC_SLOWDOWN;
|
2015-03-13 13:56:14 +10:00
|
|
|
}
|
2015-04-23 14:32:40 -04:00
|
|
|
|
|
|
|
|
double
|
|
|
|
|
touchpad_lenovo_x230_accel_profile(struct motion_filter *filter,
|
|
|
|
|
void *data,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
double speed_in, /* 1000dpi-units/µs */
|
2015-08-04 15:45:53 +10:00
|
|
|
uint64_t time)
|
2015-04-23 14:32:40 -04:00
|
|
|
{
|
|
|
|
|
/* Those touchpads presents an actual lower resolution that what is
|
|
|
|
|
* advertised. We see some jumps from the cursor due to the big steps
|
|
|
|
|
* in X and Y when we are receiving data.
|
|
|
|
|
* Apply a factor to minimize those jumps at low speed, and try
|
|
|
|
|
* keeping the same feeling as regular touchpads at high speed.
|
|
|
|
|
* It still feels slower but it is usable at least */
|
2015-08-04 16:01:20 +10:00
|
|
|
double factor; /* unitless */
|
2015-04-23 14:32:40 -04:00
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
|
2015-08-04 16:01:20 +10:00
|
|
|
double f1, f2; /* unitless */
|
2015-04-23 14:32:40 -04:00
|
|
|
const double max_accel = accel_filter->accel *
|
2015-08-31 14:05:11 +10:00
|
|
|
X230_TP_MAGIC_LOW_RES_FACTOR; /* unitless factor */
|
2015-04-23 14:32:40 -04:00
|
|
|
const double threshold = accel_filter->threshold /
|
2015-08-31 14:05:11 +10:00
|
|
|
X230_TP_MAGIC_LOW_RES_FACTOR; /* units/us */
|
|
|
|
|
const double incline = accel_filter->incline * X230_TP_MAGIC_LOW_RES_FACTOR;
|
2015-04-23 14:32:40 -04:00
|
|
|
|
2015-08-05 13:39:33 +10:00
|
|
|
/* Note: the magic values in this function are obtained by
|
|
|
|
|
* trial-and-error. No other meaning should be interpreted.
|
|
|
|
|
* The calculation is a compressed form of
|
|
|
|
|
* pointer_accel_profile_linear(), look at the git history of that
|
2016-04-03 01:47:43 +01:00
|
|
|
* function for an explanation of what the min/max/etc. does.
|
2015-08-05 13:39:33 +10:00
|
|
|
*/
|
2015-08-31 14:05:11 +10:00
|
|
|
speed_in *= X230_MAGIC_SLOWDOWN / X230_TP_MAGIC_LOW_RES_FACTOR;
|
2015-04-23 14:32:40 -04:00
|
|
|
|
2015-08-04 16:04:06 +10:00
|
|
|
f1 = min(1, v_us2ms(speed_in) * 5);
|
|
|
|
|
f2 = 1 + (v_us2ms(speed_in) - v_us2ms(threshold)) * incline;
|
2015-04-23 14:32:40 -04:00
|
|
|
|
2015-08-04 16:01:20 +10:00
|
|
|
factor = min(max_accel, f2 > 1 ? f2 : f1);
|
2015-04-23 14:32:40 -04:00
|
|
|
|
2015-08-31 14:05:11 +10:00
|
|
|
return factor * X230_MAGIC_SLOWDOWN / X230_TP_MAGIC_LOW_RES_FACTOR;
|
2015-04-23 14:32:40 -04:00
|
|
|
}
|
2015-07-28 14:45:51 +10:00
|
|
|
|
2015-07-28 16:02:05 +10:00
|
|
|
double
|
|
|
|
|
trackpoint_accel_profile(struct motion_filter *filter,
|
|
|
|
|
void *data,
|
2016-12-15 11:03:03 +10:00
|
|
|
double speed_in, /* device units/µs */
|
2015-07-28 16:02:05 +10:00
|
|
|
uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *accel_filter =
|
|
|
|
|
(struct pointer_accelerator *)filter;
|
|
|
|
|
double max_accel = accel_filter->accel; /* unitless factor */
|
|
|
|
|
double threshold = accel_filter->threshold; /* units/ms */
|
|
|
|
|
const double incline = accel_filter->incline;
|
2016-12-15 10:51:16 +10:00
|
|
|
double dpi_factor = accel_filter->dpi/(double)DEFAULT_MOUSE_DPI;
|
2015-07-28 16:02:05 +10:00
|
|
|
double factor;
|
|
|
|
|
|
|
|
|
|
/* dpi_factor is always < 1.0, increase max_accel, reduce
|
|
|
|
|
the threshold so it kicks in earlier */
|
|
|
|
|
max_accel /= dpi_factor;
|
|
|
|
|
threshold *= dpi_factor;
|
|
|
|
|
|
|
|
|
|
/* see pointer_accel_profile_linear for a long description */
|
|
|
|
|
if (v_us2ms(speed_in) < 0.07)
|
|
|
|
|
factor = 10 * v_us2ms(speed_in) + 0.3;
|
|
|
|
|
else if (speed_in < threshold)
|
|
|
|
|
factor = 1;
|
|
|
|
|
else
|
|
|
|
|
factor = incline * v_us2ms(speed_in - threshold) + 1;
|
|
|
|
|
|
|
|
|
|
factor = min(max_accel, factor);
|
|
|
|
|
|
|
|
|
|
return factor;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-28 14:45:51 +10:00
|
|
|
struct motion_filter_interface accelerator_interface = {
|
2015-08-27 13:13:47 +10:00
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_ADAPTIVE,
|
2017-01-18 17:58:36 +10:00
|
|
|
.filter = accelerator_filter_pre_normalized,
|
2015-08-17 16:32:20 +10:00
|
|
|
.filter_constant = accelerator_filter_noop,
|
2015-08-17 16:17:41 +10:00
|
|
|
.restart = accelerator_restart,
|
|
|
|
|
.destroy = accelerator_destroy,
|
|
|
|
|
.set_speed = accelerator_set_speed,
|
2015-07-28 14:45:51 +10:00
|
|
|
};
|
|
|
|
|
|
2015-07-28 15:06:13 +10:00
|
|
|
static struct pointer_accelerator *
|
|
|
|
|
create_default_filter(int dpi)
|
2015-07-28 14:45:51 +10:00
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
|
|
|
|
filter = zalloc(sizeof *filter);
|
|
|
|
|
if (filter == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
filter->last_velocity = 0.0;
|
|
|
|
|
|
|
|
|
|
filter->trackers =
|
|
|
|
|
calloc(NUM_POINTER_TRACKERS, sizeof *filter->trackers);
|
|
|
|
|
filter->cur_tracker = 0;
|
|
|
|
|
|
|
|
|
|
filter->threshold = DEFAULT_THRESHOLD;
|
|
|
|
|
filter->accel = DEFAULT_ACCELERATION;
|
|
|
|
|
filter->incline = DEFAULT_INCLINE;
|
2016-12-15 09:22:23 +10:00
|
|
|
filter->dpi = dpi;
|
2015-07-28 14:45:51 +10:00
|
|
|
|
2015-07-28 15:06:13 +10:00
|
|
|
return filter;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_linear(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
|
|
|
|
filter = create_default_filter(dpi);
|
|
|
|
|
if (!filter)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2015-07-28 15:49:22 +10:00
|
|
|
filter->base.interface = &accelerator_interface;
|
2015-07-28 15:06:13 +10:00
|
|
|
filter->profile = pointer_accel_profile_linear;
|
|
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-28 15:49:22 +10:00
|
|
|
struct motion_filter_interface accelerator_interface_low_dpi = {
|
2015-08-27 13:13:47 +10:00
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_ADAPTIVE,
|
2017-01-18 17:58:36 +10:00
|
|
|
.filter = accelerator_filter_unnormalized,
|
2015-08-17 16:32:20 +10:00
|
|
|
.filter_constant = accelerator_filter_noop,
|
2015-08-17 16:17:41 +10:00
|
|
|
.restart = accelerator_restart,
|
|
|
|
|
.destroy = accelerator_destroy,
|
|
|
|
|
.set_speed = accelerator_set_speed,
|
2015-07-28 15:49:22 +10:00
|
|
|
};
|
|
|
|
|
|
2015-07-28 15:06:13 +10:00
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_linear_low_dpi(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
|
|
|
|
filter = create_default_filter(dpi);
|
|
|
|
|
if (!filter)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2015-07-28 15:49:22 +10:00
|
|
|
filter->base.interface = &accelerator_interface_low_dpi;
|
2015-07-28 15:06:13 +10:00
|
|
|
filter->profile = pointer_accel_profile_linear_low_dpi;
|
|
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-06 14:59:38 +10:00
|
|
|
struct motion_filter_interface accelerator_interface_touchpad = {
|
2015-08-27 13:13:47 +10:00
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_ADAPTIVE,
|
2017-01-18 17:58:36 +10:00
|
|
|
.filter = accelerator_filter_post_normalized,
|
2015-08-06 14:59:38 +10:00
|
|
|
.filter_constant = touchpad_constant_filter,
|
|
|
|
|
.restart = accelerator_restart,
|
|
|
|
|
.destroy = accelerator_destroy,
|
2016-11-14 16:47:26 +10:00
|
|
|
.set_speed = touchpad_accelerator_set_speed,
|
2015-08-06 14:59:38 +10:00
|
|
|
};
|
|
|
|
|
|
2015-07-28 15:06:13 +10:00
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_touchpad(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
|
|
|
|
filter = create_default_filter(dpi);
|
|
|
|
|
if (!filter)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2015-08-06 14:59:38 +10:00
|
|
|
filter->base.interface = &accelerator_interface_touchpad;
|
2015-07-28 15:06:13 +10:00
|
|
|
filter->profile = touchpad_accel_profile_linear;
|
|
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-28 15:53:23 +10:00
|
|
|
struct motion_filter_interface accelerator_interface_x230 = {
|
2015-08-27 13:13:47 +10:00
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_ADAPTIVE,
|
2015-08-17 16:17:41 +10:00
|
|
|
.filter = accelerator_filter_x230,
|
2015-08-31 14:05:11 +10:00
|
|
|
.filter_constant = accelerator_filter_constant_x230,
|
2015-08-17 16:17:41 +10:00
|
|
|
.restart = accelerator_restart,
|
|
|
|
|
.destroy = accelerator_destroy,
|
|
|
|
|
.set_speed = accelerator_set_speed,
|
2015-07-28 15:53:23 +10:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* The Lenovo x230 has a bad touchpad. This accel method has been
|
|
|
|
|
* trial-and-error'd, any changes to it will require re-testing everything.
|
|
|
|
|
* Don't touch this.
|
|
|
|
|
*/
|
2015-07-28 15:06:13 +10:00
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_lenovo_x230(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
2015-07-28 15:53:23 +10:00
|
|
|
filter = zalloc(sizeof *filter);
|
|
|
|
|
if (filter == NULL)
|
2015-07-28 15:06:13 +10:00
|
|
|
return NULL;
|
|
|
|
|
|
2015-07-28 15:53:23 +10:00
|
|
|
filter->base.interface = &accelerator_interface_x230;
|
2015-07-28 15:06:13 +10:00
|
|
|
filter->profile = touchpad_lenovo_x230_accel_profile;
|
2015-07-28 15:53:23 +10:00
|
|
|
filter->last_velocity = 0.0;
|
|
|
|
|
|
|
|
|
|
filter->trackers =
|
|
|
|
|
calloc(NUM_POINTER_TRACKERS, sizeof *filter->trackers);
|
|
|
|
|
filter->cur_tracker = 0;
|
|
|
|
|
|
|
|
|
|
filter->threshold = X230_THRESHOLD;
|
|
|
|
|
filter->accel = X230_ACCELERATION; /* unitless factor */
|
|
|
|
|
filter->incline = X230_INCLINE; /* incline of the acceleration function */
|
2016-12-15 09:22:23 +10:00
|
|
|
filter->dpi = dpi;
|
2015-07-28 15:06:13 +10:00
|
|
|
|
2015-07-28 14:45:51 +10:00
|
|
|
return &filter->base;
|
|
|
|
|
}
|
2015-07-28 16:02:05 +10:00
|
|
|
|
|
|
|
|
struct motion_filter_interface accelerator_interface_trackpoint = {
|
2015-08-27 13:13:47 +10:00
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_ADAPTIVE,
|
2017-01-18 17:58:36 +10:00
|
|
|
.filter = accelerator_filter_unnormalized,
|
2015-08-17 16:32:20 +10:00
|
|
|
.filter_constant = accelerator_filter_noop,
|
2015-08-17 16:17:41 +10:00
|
|
|
.restart = accelerator_restart,
|
|
|
|
|
.destroy = accelerator_destroy,
|
|
|
|
|
.set_speed = accelerator_set_speed,
|
2015-07-28 16:02:05 +10:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_trackpoint(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator *filter;
|
|
|
|
|
|
|
|
|
|
filter = create_default_filter(dpi);
|
|
|
|
|
if (!filter)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
filter->base.interface = &accelerator_interface_trackpoint;
|
|
|
|
|
filter->profile = trackpoint_accel_profile;
|
|
|
|
|
filter->threshold = DEFAULT_THRESHOLD;
|
|
|
|
|
filter->accel = DEFAULT_ACCELERATION;
|
|
|
|
|
filter->incline = DEFAULT_INCLINE;
|
2016-12-15 09:22:23 +10:00
|
|
|
filter->dpi = dpi;
|
2015-07-28 16:02:05 +10:00
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|
2015-08-27 13:13:47 +10:00
|
|
|
|
|
|
|
|
static struct normalized_coords
|
|
|
|
|
accelerator_filter_flat(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *unaccelerated,
|
2015-08-27 13:13:47 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator_flat *accel_filter =
|
|
|
|
|
(struct pointer_accelerator_flat *)filter;
|
|
|
|
|
double factor; /* unitless factor */
|
|
|
|
|
struct normalized_coords accelerated;
|
|
|
|
|
|
|
|
|
|
/* You want flat acceleration, you get flat acceleration for the
|
|
|
|
|
* device */
|
|
|
|
|
factor = accel_filter->factor;
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
accelerated.x = factor * unaccelerated->x;
|
|
|
|
|
accelerated.y = factor * unaccelerated->y;
|
2015-08-27 13:13:47 +10:00
|
|
|
|
|
|
|
|
return accelerated;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
accelerator_set_speed_flat(struct motion_filter *filter,
|
|
|
|
|
double speed_adjustment)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator_flat *accel_filter =
|
|
|
|
|
(struct pointer_accelerator_flat *)filter;
|
|
|
|
|
|
|
|
|
|
assert(speed_adjustment >= -1.0 && speed_adjustment <= 1.0);
|
|
|
|
|
|
|
|
|
|
/* Speed rage is 0-200% of the nominal speed, with 0 mapping to the
|
|
|
|
|
* nominal speed. Anything above 200 is pointless, we're already
|
|
|
|
|
* skipping over ever second pixel at 200% speed.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
accel_filter->factor = 1 + speed_adjustment;
|
|
|
|
|
filter->speed_adjustment = speed_adjustment;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
accelerator_destroy_flat(struct motion_filter *filter)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator_flat *accel =
|
|
|
|
|
(struct pointer_accelerator_flat *) filter;
|
|
|
|
|
|
|
|
|
|
free(accel);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct motion_filter_interface accelerator_interface_flat = {
|
|
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_FLAT,
|
|
|
|
|
.filter = accelerator_filter_flat,
|
|
|
|
|
.filter_constant = accelerator_filter_noop,
|
|
|
|
|
.restart = NULL,
|
|
|
|
|
.destroy = accelerator_destroy_flat,
|
|
|
|
|
.set_speed = accelerator_set_speed_flat,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_flat(int dpi)
|
|
|
|
|
{
|
|
|
|
|
struct pointer_accelerator_flat *filter;
|
|
|
|
|
|
|
|
|
|
filter = zalloc(sizeof *filter);
|
|
|
|
|
if (filter == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
filter->base.interface = &accelerator_interface_flat;
|
2016-12-15 09:22:23 +10:00
|
|
|
filter->dpi = dpi;
|
2015-08-27 13:13:47 +10:00
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|
2016-01-06 15:26:49 +10:00
|
|
|
|
2016-06-21 15:20:08 +10:00
|
|
|
static inline struct normalized_coords
|
|
|
|
|
tablet_accelerator_filter_flat_mouse(struct tablet_accelerator_flat *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *units)
|
2016-06-21 15:20:08 +10:00
|
|
|
{
|
|
|
|
|
struct normalized_coords accelerated;
|
|
|
|
|
|
|
|
|
|
/*
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
Tablets are high res (Intuos 4 is 5080 dpi) and unmodified deltas
|
|
|
|
|
are way too high. Slow it down to the equivalent of a 1000dpi
|
|
|
|
|
mouse. The ratio of that is:
|
2016-06-21 15:20:08 +10:00
|
|
|
ratio = 1000/(resolution_per_mm * 25.4)
|
|
|
|
|
|
|
|
|
|
i.e. on the Intuos4 it's a ratio of ~1/5.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
accelerated.x = units->x * filter->xres_scale;
|
|
|
|
|
accelerated.y = units->y * filter->yres_scale;
|
|
|
|
|
|
|
|
|
|
accelerated.x *= filter->factor;
|
|
|
|
|
accelerated.y *= filter->factor;
|
|
|
|
|
|
|
|
|
|
return accelerated;
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-06 15:26:49 +10:00
|
|
|
static struct normalized_coords
|
2016-06-21 15:20:08 +10:00
|
|
|
tablet_accelerator_filter_flat_pen(struct tablet_accelerator_flat *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *units)
|
2016-01-06 15:26:49 +10:00
|
|
|
{
|
|
|
|
|
struct normalized_coords accelerated;
|
|
|
|
|
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
/* Tablet input is in device units, output is supposed to be in
|
|
|
|
|
* logical pixels roughly equivalent to a mouse/touchpad.
|
2016-01-06 15:26:49 +10:00
|
|
|
*
|
|
|
|
|
* This is a magical constant found by trial and error. On a 96dpi
|
|
|
|
|
* screen 0.4mm of movement correspond to 1px logical pixel which
|
|
|
|
|
* is almost identical to the tablet mapped to screen in absolute
|
|
|
|
|
* mode. Tested on a Intuos5, other tablets may vary.
|
|
|
|
|
*/
|
2016-06-21 15:20:08 +10:00
|
|
|
const double DPI_CONVERSION = 96.0/25.4 * 2.5; /* unitless factor */
|
|
|
|
|
struct normalized_coords mm;
|
2016-01-06 15:26:49 +10:00
|
|
|
|
2016-06-21 15:20:08 +10:00
|
|
|
mm.x = 1.0 * units->x/filter->xres;
|
|
|
|
|
mm.y = 1.0 * units->y/filter->yres;
|
|
|
|
|
accelerated.x = mm.x * filter->factor * DPI_CONVERSION;
|
|
|
|
|
accelerated.y = mm.y * filter->factor * DPI_CONVERSION;
|
2016-01-06 15:26:49 +10:00
|
|
|
|
2016-06-21 15:20:08 +10:00
|
|
|
return accelerated;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct normalized_coords
|
|
|
|
|
tablet_accelerator_filter_flat(struct motion_filter *filter,
|
filter: change the filter functions to take raw device coordinates
We used to normalize all deltas to equivalents of a 1000dpi mouse before
passing it into the acceleration functions. This has a bunch of drawbacks, not
least that we already have to un-normalize back into device units for a few
devices already (trackpoints, tablet, low-dpi mice).
Switch the filter code over to use device units, relying on the dpi set
earlier during filter creation to convert to normalized. To make things easy,
the output of the filter code is still normalized data, i.e. data ready to be
handed to the libinput caller.
No effective functional changes. For touchpads, we still send normalized
coordinates (for now, anyway). For the various filter methods, we either drop
the places where we unnormalized before or we normalize where needed.
Two possible changes: for trackpoints and low-dpi mice we had a max dpi factor
of 1.0 before - now we don't anymore. This was only the case if a low-dpi
mouse had more than 1000dpi (never true) or a trackpoint had a const accel
lower than 1.0 (yeah, whatever).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-12-15 08:36:22 +10:00
|
|
|
const struct device_float_coords *units,
|
2016-06-21 15:20:08 +10:00
|
|
|
void *data, uint64_t time)
|
|
|
|
|
{
|
|
|
|
|
struct tablet_accelerator_flat *accel_filter =
|
|
|
|
|
(struct tablet_accelerator_flat *)filter;
|
|
|
|
|
struct libinput_tablet_tool *tool = (struct libinput_tablet_tool*)data;
|
|
|
|
|
enum libinput_tablet_tool_type type;
|
|
|
|
|
struct normalized_coords accel;
|
|
|
|
|
|
|
|
|
|
type = libinput_tablet_tool_get_type(tool);
|
|
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
|
case LIBINPUT_TABLET_TOOL_TYPE_MOUSE:
|
|
|
|
|
case LIBINPUT_TABLET_TOOL_TYPE_LENS:
|
|
|
|
|
accel = tablet_accelerator_filter_flat_mouse(accel_filter,
|
|
|
|
|
units);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
accel = tablet_accelerator_filter_flat_pen(accel_filter,
|
|
|
|
|
units);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return accel;
|
2016-01-06 15:26:49 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
tablet_accelerator_set_speed(struct motion_filter *filter,
|
|
|
|
|
double speed_adjustment)
|
|
|
|
|
{
|
|
|
|
|
struct tablet_accelerator_flat *accel_filter =
|
|
|
|
|
(struct tablet_accelerator_flat *)filter;
|
|
|
|
|
|
|
|
|
|
assert(speed_adjustment >= -1.0 && speed_adjustment <= 1.0);
|
|
|
|
|
|
|
|
|
|
accel_filter->factor = speed_adjustment + 1.0;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
tablet_accelerator_destroy(struct motion_filter *filter)
|
|
|
|
|
{
|
|
|
|
|
struct tablet_accelerator_flat *accel_filter =
|
|
|
|
|
(struct tablet_accelerator_flat *)filter;
|
|
|
|
|
|
|
|
|
|
free(accel_filter);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct motion_filter_interface accelerator_interface_tablet = {
|
|
|
|
|
.type = LIBINPUT_CONFIG_ACCEL_PROFILE_FLAT,
|
|
|
|
|
.filter = tablet_accelerator_filter_flat,
|
|
|
|
|
.filter_constant = NULL,
|
|
|
|
|
.restart = NULL,
|
|
|
|
|
.destroy = tablet_accelerator_destroy,
|
|
|
|
|
.set_speed = tablet_accelerator_set_speed,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct tablet_accelerator_flat *
|
|
|
|
|
create_tablet_filter_flat(int xres, int yres)
|
|
|
|
|
{
|
|
|
|
|
struct tablet_accelerator_flat *filter;
|
|
|
|
|
|
|
|
|
|
filter = zalloc(sizeof *filter);
|
|
|
|
|
if (filter == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2016-06-21 15:20:08 +10:00
|
|
|
filter->factor = 1.0;
|
2016-01-06 15:26:49 +10:00
|
|
|
filter->xres = xres;
|
|
|
|
|
filter->yres = yres;
|
2016-06-21 15:20:08 +10:00
|
|
|
filter->xres_scale = DEFAULT_MOUSE_DPI/(25.4 * xres);
|
|
|
|
|
filter->yres_scale = DEFAULT_MOUSE_DPI/(25.4 * yres);
|
2016-01-06 15:26:49 +10:00
|
|
|
|
|
|
|
|
return filter;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct motion_filter *
|
|
|
|
|
create_pointer_accelerator_filter_tablet(int xres, int yres)
|
|
|
|
|
{
|
|
|
|
|
struct tablet_accelerator_flat *filter;
|
|
|
|
|
|
|
|
|
|
filter = create_tablet_filter_flat(xres, yres);
|
|
|
|
|
if (!filter)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
filter->base.interface = &accelerator_interface_tablet;
|
|
|
|
|
|
|
|
|
|
return &filter->base;
|
|
|
|
|
}
|