2015-04-10 15:37:15 +10:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2015 Red Hat, Inc.
|
|
|
|
|
*
|
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:
|
2015-04-10 15:37:15 +10: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.
|
2015-04-10 15:37:15 +10:00
|
|
|
*/
|
2016-12-05 20:56:23 +10:00
|
|
|
|
|
|
|
|
#include "config.h"
|
2015-04-10 15:37:15 +10:00
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
#include <errno.h>
|
2025-07-01 16:30:11 +10:00
|
|
|
#include <getopt.h>
|
2015-04-10 15:37:15 +10:00
|
|
|
#include <stdbool.h>
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
2016-11-14 16:32:16 +10:00
|
|
|
#include "filter.h"
|
|
|
|
|
#include "libinput-util.h"
|
2015-07-27 17:51:52 +08:00
|
|
|
|
2015-04-10 15:37:15 +10:00
|
|
|
static void
|
|
|
|
|
print_ptraccel_deltas(struct motion_filter *filter, double step)
|
|
|
|
|
{
|
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 motion;
|
|
|
|
|
struct normalized_coords accel;
|
2015-04-10 15:37:15 +10:00
|
|
|
uint64_t time = 0;
|
|
|
|
|
double i;
|
|
|
|
|
|
|
|
|
|
printf("# gnuplot:\n");
|
|
|
|
|
printf("# set xlabel dx unaccelerated\n");
|
|
|
|
|
printf("# set ylabel dx accelerated\n");
|
|
|
|
|
printf("# set style data lines\n");
|
|
|
|
|
printf("# plot \"gnuplot.data\" using 1:2 title \"step %.2f\"\n", step);
|
|
|
|
|
printf("#\n");
|
|
|
|
|
|
|
|
|
|
/* Accel flattens out after 15 and becomes linear */
|
2025-04-03 13:39:01 +10:00
|
|
|
for (i = 0.0; i < 15.0; i += step) { // NOLINT: security.FloatLoopCounter
|
2015-04-10 15:37:15 +10:00
|
|
|
motion.x = i;
|
|
|
|
|
motion.y = 0;
|
2015-07-27 17:51:52 +08:00
|
|
|
time += us(12500); /* pretend 80Hz data */
|
2015-04-10 15:37:15 +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
|
|
|
accel = filter_dispatch(filter, &motion, NULL, time);
|
2015-04-10 15:37:15 +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
|
|
|
printf("%.2f %.3f\n", i, accel.x);
|
2015-04-10 15:37:15 +10:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
print_ptraccel_movement(struct motion_filter *filter,
|
|
|
|
|
int nevents,
|
|
|
|
|
double max_dx,
|
|
|
|
|
double step)
|
|
|
|
|
{
|
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 motion;
|
|
|
|
|
struct normalized_coords accel;
|
2015-04-10 15:37:15 +10:00
|
|
|
uint64_t time = 0;
|
|
|
|
|
double dx;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
printf("# gnuplot:\n");
|
|
|
|
|
printf("# set xlabel \"event number\"\n");
|
|
|
|
|
printf("# set ylabel \"delta motion\"\n");
|
|
|
|
|
printf("# set style data lines\n");
|
|
|
|
|
printf("# plot \"gnuplot.data\" using 1:2 title \"dx out\", \\\n");
|
|
|
|
|
printf("# \"gnuplot.data\" using 1:3 title \"dx in\"\n");
|
|
|
|
|
printf("#\n");
|
|
|
|
|
|
|
|
|
|
if (nevents == 0) {
|
|
|
|
|
if (step > 1.0)
|
|
|
|
|
nevents = max_dx;
|
|
|
|
|
else
|
2025-07-01 16:30:11 +10:00
|
|
|
nevents = 1.0 * max_dx / step + 0.5;
|
2015-04-10 15:37:15 +10:00
|
|
|
|
|
|
|
|
/* Print more events than needed so we see the curve
|
|
|
|
|
* flattening out */
|
|
|
|
|
nevents *= 1.5;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dx = 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nevents; i++) {
|
|
|
|
|
motion.x = dx;
|
|
|
|
|
motion.y = 0;
|
2015-07-27 17:51:52 +08:00
|
|
|
time += us(12500); /* pretend 80Hz data */
|
2015-04-10 15:37:15 +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
|
|
|
accel = filter_dispatch(filter, &motion, NULL, time);
|
2015-04-10 15:37:15 +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
|
|
|
printf("%d %.3f %.3f\n", i, accel.x, dx);
|
2015-04-10 15:37:15 +10:00
|
|
|
|
|
|
|
|
if (dx < max_dx)
|
|
|
|
|
dx += step;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2025-07-01 16:30:11 +10:00
|
|
|
print_ptraccel_sequence(struct motion_filter *filter, int nevents, double *deltas)
|
2015-04-10 15:37:15 +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
|
|
|
struct device_float_coords motion;
|
|
|
|
|
struct normalized_coords accel;
|
2015-04-10 15:37:15 +10:00
|
|
|
uint64_t time = 0;
|
|
|
|
|
double *dx;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
printf("# gnuplot:\n");
|
|
|
|
|
printf("# set xlabel \"event number\"\n");
|
|
|
|
|
printf("# set ylabel \"delta motion\"\n");
|
|
|
|
|
printf("# set style data lines\n");
|
|
|
|
|
printf("# plot \"gnuplot.data\" using 1:2 title \"dx out\", \\\n");
|
|
|
|
|
printf("# \"gnuplot.data\" using 1:3 title \"dx in\"\n");
|
|
|
|
|
printf("#\n");
|
|
|
|
|
|
|
|
|
|
dx = deltas;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nevents; i++, dx++) {
|
|
|
|
|
motion.x = *dx;
|
|
|
|
|
motion.y = 0;
|
2015-07-27 17:51:52 +08:00
|
|
|
time += us(12500); /* pretend 80Hz data */
|
2015-04-10 15:37:15 +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
|
|
|
accel = filter_dispatch(filter, &motion, NULL, time);
|
2015-04-10 15:37:15 +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
|
|
|
printf("%d %.3f %.3f\n", i, accel.x, *dx);
|
2015-04-10 15:37:15 +10:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-16 08:22:54 +10:00
|
|
|
/* mm/s → units/µs */
|
|
|
|
|
static inline double
|
|
|
|
|
mmps_to_upus(double mmps, int dpi)
|
|
|
|
|
{
|
2025-07-01 16:30:11 +10:00
|
|
|
return mmps * (dpi / 25.4) / 1e6;
|
2016-12-16 08:22:54 +10:00
|
|
|
}
|
|
|
|
|
|
2015-04-10 15:37:15 +10:00
|
|
|
static void
|
2025-07-01 16:30:11 +10:00
|
|
|
print_accel_func(struct motion_filter *filter, accel_profile_func_t profile, int dpi)
|
2015-04-10 15:37:15 +10:00
|
|
|
{
|
2016-12-16 08:22:54 +10:00
|
|
|
double mmps;
|
2015-04-10 15:37:15 +10:00
|
|
|
|
|
|
|
|
printf("# gnuplot:\n");
|
2016-12-16 08:22:54 +10:00
|
|
|
printf("# set xlabel \"speed (mm/s)\"\n");
|
2015-04-10 15:37:15 +10:00
|
|
|
printf("# set ylabel \"raw accel factor\"\n");
|
|
|
|
|
printf("# set style data lines\n");
|
2016-12-16 08:22:54 +10:00
|
|
|
printf("# plot \"gnuplot.data\" using 1:2 title 'accel factor'\n");
|
|
|
|
|
printf("#\n");
|
2018-06-27 15:54:04 +10:00
|
|
|
printf("# data: velocity(mm/s) factor velocity(units/us) velocity(units/ms)\n");
|
2025-08-04 16:34:55 +10:00
|
|
|
for (mmps = 0.0; mmps < 1000.0; // NOLINT: security.FloatLoopCounter
|
|
|
|
|
mmps += 1) {
|
2016-12-16 08:22:54 +10:00
|
|
|
double units_per_us = mmps_to_upus(mmps, dpi);
|
2018-06-27 15:54:04 +10:00
|
|
|
double units_per_ms = units_per_us * 1000.0;
|
2016-12-16 08:22:54 +10:00
|
|
|
double result = profile(filter, NULL, units_per_us, 0 /* time */);
|
2025-07-01 16:30:11 +10:00
|
|
|
printf("%.8f\t%.4f\t%.8f\t%.8f\n",
|
|
|
|
|
mmps,
|
|
|
|
|
result,
|
|
|
|
|
units_per_us,
|
|
|
|
|
units_per_ms);
|
2015-04-10 15:37:15 +10:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
usage(void)
|
|
|
|
|
{
|
2025-07-01 16:30:11 +10:00
|
|
|
printf("Usage: %s [options] [dx1] [dx2] [...] > gnuplot.data\n",
|
|
|
|
|
program_invocation_short_name);
|
2015-04-10 15:37:15 +10:00
|
|
|
printf("\n"
|
|
|
|
|
"Options:\n"
|
2018-05-10 14:49:38 +10:00
|
|
|
"--mode=<accel|motion|delta|sequence> \n"
|
|
|
|
|
" accel ... print accel factor (default)\n"
|
|
|
|
|
" motion ... print motion to accelerated motion\n"
|
2015-04-10 15:37:15 +10:00
|
|
|
" delta ... print delta to accelerated delta\n"
|
|
|
|
|
" sequence ... print motion for custom delta sequence\n"
|
2015-06-19 16:07:10 +10:00
|
|
|
"--maxdx=<double> ... in motion mode only. Stop increasing dx at maxdx\n"
|
|
|
|
|
"--steps=<double> ... in motion and delta modes only. Increase dx by step each round\n"
|
|
|
|
|
"--speed=<double> ... accel speed [-1, 1], default 0\n"
|
2015-06-19 16:19:27 +10:00
|
|
|
"--dpi=<int> ... device resolution in DPI (default: 1000)\n"
|
2015-07-31 12:29:23 +10:00
|
|
|
"--filter=<linear|low-dpi|touchpad|x230|trackpoint> \n"
|
|
|
|
|
" linear ... the default motion filter\n"
|
|
|
|
|
" low-dpi ... low-dpi filter, use --dpi with this argument\n"
|
|
|
|
|
" touchpad ... the touchpad motion filter\n"
|
2022-11-22 09:56:12 +10:00
|
|
|
" x230 ... custom filter for the Lenovo x230 touchpad\n"
|
2015-07-31 12:29:23 +10:00
|
|
|
" trackpoint... trackpoint motion filter\n"
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
" custom ... custom motion filter, use --custom-points and --custom-step with this argument\n"
|
|
|
|
|
"--custom-points=\"<double>;...;<double>\" ... n points defining a custom acceleration function\n"
|
|
|
|
|
"--custom-step=<double> ... distance along the x-axis between each point, \n"
|
|
|
|
|
" starting from 0. defaults to 1.0\n"
|
2015-04-10 15:37:15 +10:00
|
|
|
"\n"
|
|
|
|
|
"If extra arguments are present and mode is not given, mode defaults to 'sequence'\n"
|
|
|
|
|
"and the arguments are interpreted as sequence of delta x coordinates\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"If stdin is a pipe, mode defaults to 'sequence' and the pipe is read \n"
|
|
|
|
|
"for delta coordinates\n"
|
|
|
|
|
"\n"
|
2016-11-14 16:50:55 +10:00
|
|
|
"Delta coordinates passed into this tool must be in dpi as\n"
|
|
|
|
|
"specified by the --dpi argument\n"
|
|
|
|
|
"\n"
|
2015-04-10 15:37:15 +10:00
|
|
|
"Output best viewed with gnuplot. See output for gnuplot commands\n");
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 15:01:02 +10:00
|
|
|
enum mode {
|
|
|
|
|
ACCEL,
|
|
|
|
|
MOTION,
|
|
|
|
|
DELTA,
|
|
|
|
|
SEQUENCE,
|
|
|
|
|
};
|
|
|
|
|
|
2015-04-10 15:37:15 +10:00
|
|
|
int
|
2015-05-01 11:41:12 +10:00
|
|
|
main(int argc, char **argv)
|
|
|
|
|
{
|
2015-04-10 15:37:15 +10:00
|
|
|
struct motion_filter *filter;
|
2025-07-01 16:30:11 +10:00
|
|
|
double step = 0.1, max_dx = 10;
|
2015-04-10 15:37:15 +10:00
|
|
|
int nevents = 0;
|
2018-05-11 15:01:02 +10:00
|
|
|
enum mode mode = ACCEL;
|
2015-04-10 15:37:15 +10:00
|
|
|
double custom_deltas[1024];
|
|
|
|
|
double speed = 0.0;
|
2015-06-19 16:19:27 +10:00
|
|
|
int dpi = 1000;
|
2018-08-17 15:12:58 +02:00
|
|
|
bool use_averaging = false;
|
2015-07-31 12:29:23 +10:00
|
|
|
const char *filter_type = "linear";
|
|
|
|
|
accel_profile_func_t profile = NULL;
|
2018-08-22 11:08:49 +10:00
|
|
|
double tp_multiplier = 1.0;
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
struct libinput_config_accel_custom_func custom_func = {
|
|
|
|
|
.step = 1.0,
|
|
|
|
|
.npoints = 2,
|
2025-07-01 16:30:11 +10:00
|
|
|
.points = { 0.0, 1.0 },
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
};
|
|
|
|
|
struct libinput_config_accel *accel_config =
|
|
|
|
|
libinput_config_accel_create(LIBINPUT_CONFIG_ACCEL_PROFILE_CUSTOM);
|
2015-06-19 16:19:27 +10:00
|
|
|
|
2015-04-10 15:37:15 +10:00
|
|
|
enum {
|
2016-11-02 11:19:28 +10:00
|
|
|
OPT_HELP = 1,
|
|
|
|
|
OPT_MODE,
|
2015-04-10 15:37:15 +10:00
|
|
|
OPT_NEVENTS,
|
|
|
|
|
OPT_MAXDX,
|
|
|
|
|
OPT_STEP,
|
|
|
|
|
OPT_SPEED,
|
2015-06-19 16:19:27 +10:00
|
|
|
OPT_DPI,
|
2015-07-31 12:29:23 +10:00
|
|
|
OPT_FILTER,
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
OPT_CUSTOM_POINTS,
|
|
|
|
|
OPT_CUSTOM_STEP,
|
2015-04-10 15:37:15 +10:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
|
int c;
|
|
|
|
|
int option_index = 0;
|
|
|
|
|
static struct option long_options[] = {
|
2025-07-01 16:30:11 +10:00
|
|
|
{ "help", 0, 0, OPT_HELP },
|
|
|
|
|
{ "mode", 1, 0, OPT_MODE },
|
|
|
|
|
{ "nevents", 1, 0, OPT_NEVENTS },
|
|
|
|
|
{ "maxdx", 1, 0, OPT_MAXDX },
|
|
|
|
|
{ "step", 1, 0, OPT_STEP },
|
|
|
|
|
{ "speed", 1, 0, OPT_SPEED },
|
|
|
|
|
{ "dpi", 1, 0, OPT_DPI },
|
|
|
|
|
{ "filter", 1, 0, OPT_FILTER },
|
|
|
|
|
{ "custom-points", 1, 0, OPT_CUSTOM_POINTS },
|
|
|
|
|
{ "custom-step", 1, 0, OPT_CUSTOM_STEP },
|
|
|
|
|
{ 0, 0, 0, 0 }
|
2015-04-10 15:37:15 +10:00
|
|
|
};
|
|
|
|
|
|
2025-07-01 16:30:11 +10:00
|
|
|
c = getopt_long(argc, argv, "", long_options, &option_index);
|
2015-04-10 15:37:15 +10:00
|
|
|
if (c == -1)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
switch (c) {
|
2016-11-02 11:19:28 +10:00
|
|
|
case OPT_HELP:
|
|
|
|
|
usage();
|
|
|
|
|
exit(0);
|
|
|
|
|
break;
|
2015-04-10 15:37:15 +10:00
|
|
|
case OPT_MODE:
|
2015-05-26 08:46:05 +10:00
|
|
|
if (streq(optarg, "accel"))
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = ACCEL;
|
2015-05-26 08:46:05 +10:00
|
|
|
else if (streq(optarg, "motion"))
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = MOTION;
|
2015-05-26 08:46:05 +10:00
|
|
|
else if (streq(optarg, "delta"))
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = DELTA;
|
2015-05-26 08:46:05 +10:00
|
|
|
else if (streq(optarg, "sequence"))
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = SEQUENCE;
|
2015-04-10 15:37:15 +10:00
|
|
|
else {
|
|
|
|
|
usage();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case OPT_NEVENTS:
|
|
|
|
|
nevents = atoi(optarg);
|
|
|
|
|
if (nevents == 0) {
|
|
|
|
|
usage();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case OPT_MAXDX:
|
|
|
|
|
max_dx = strtod(optarg, NULL);
|
|
|
|
|
if (max_dx == 0.0) {
|
|
|
|
|
usage();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case OPT_STEP:
|
|
|
|
|
step = strtod(optarg, NULL);
|
|
|
|
|
if (step == 0.0) {
|
|
|
|
|
usage();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case OPT_SPEED:
|
|
|
|
|
speed = strtod(optarg, NULL);
|
|
|
|
|
break;
|
2015-06-19 16:19:27 +10:00
|
|
|
case OPT_DPI:
|
|
|
|
|
dpi = strtod(optarg, NULL);
|
|
|
|
|
break;
|
2015-07-31 12:29:23 +10:00
|
|
|
case OPT_FILTER:
|
|
|
|
|
filter_type = optarg;
|
|
|
|
|
break;
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
case OPT_CUSTOM_POINTS: {
|
|
|
|
|
size_t npoints;
|
2025-07-01 16:30:11 +10:00
|
|
|
_autofree_ double *points =
|
|
|
|
|
double_array_from_string(optarg, ";", &npoints);
|
|
|
|
|
if (!points || npoints < LIBINPUT_ACCEL_NPOINTS_MIN ||
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
npoints > LIBINPUT_ACCEL_NPOINTS_MAX) {
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"Invalid --custom-points\n"
|
|
|
|
|
"Please provide at least 2 points separated by a semicolon\n"
|
|
|
|
|
" e.g. --custom-points=\"1.0;1.5\"\n");
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
custom_func.npoints = npoints;
|
2025-07-01 16:30:11 +10:00
|
|
|
memcpy(custom_func.points, points, sizeof(*points) * npoints);
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case OPT_CUSTOM_STEP:
|
|
|
|
|
custom_func.step = strtod(optarg, NULL);
|
|
|
|
|
break;
|
2015-04-10 15:37:15 +10:00
|
|
|
default:
|
|
|
|
|
usage();
|
|
|
|
|
exit(1);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-31 12:29:23 +10:00
|
|
|
if (streq(filter_type, "linear")) {
|
2025-07-01 16:30:11 +10:00
|
|
|
filter = create_pointer_accelerator_filter_linear(dpi, use_averaging);
|
2015-07-31 12:29:23 +10:00
|
|
|
profile = pointer_accel_profile_linear;
|
|
|
|
|
} else if (streq(filter_type, "low-dpi")) {
|
2025-07-01 16:30:11 +10:00
|
|
|
filter =
|
|
|
|
|
create_pointer_accelerator_filter_linear_low_dpi(dpi,
|
|
|
|
|
use_averaging);
|
2015-07-31 12:29:23 +10:00
|
|
|
profile = pointer_accel_profile_linear_low_dpi;
|
|
|
|
|
} else if (streq(filter_type, "touchpad")) {
|
2018-08-17 15:12:58 +02:00
|
|
|
filter = create_pointer_accelerator_filter_touchpad(dpi,
|
2025-07-01 16:30:11 +10:00
|
|
|
0,
|
|
|
|
|
0,
|
2018-08-17 15:12:58 +02:00
|
|
|
use_averaging);
|
2015-07-31 12:29:23 +10:00
|
|
|
profile = touchpad_accel_profile_linear;
|
|
|
|
|
} else if (streq(filter_type, "x230")) {
|
2018-08-17 15:12:58 +02:00
|
|
|
filter = create_pointer_accelerator_filter_lenovo_x230(dpi,
|
|
|
|
|
use_averaging);
|
2015-07-31 12:29:23 +10:00
|
|
|
profile = touchpad_lenovo_x230_accel_profile;
|
|
|
|
|
} else if (streq(filter_type, "trackpoint")) {
|
2018-08-17 15:12:58 +02:00
|
|
|
filter = create_pointer_accelerator_filter_trackpoint(tp_multiplier,
|
|
|
|
|
use_averaging);
|
2018-06-27 15:53:23 +10:00
|
|
|
profile = trackpoint_accel_profile;
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
} else if (streq(filter_type, "custom")) {
|
|
|
|
|
libinput_config_accel_set_points(accel_config,
|
|
|
|
|
LIBINPUT_ACCEL_TYPE_MOTION,
|
|
|
|
|
custom_func.step,
|
|
|
|
|
custom_func.npoints,
|
|
|
|
|
custom_func.points);
|
|
|
|
|
filter = create_custom_accelerator_filter();
|
|
|
|
|
profile = custom_accel_profile_motion;
|
|
|
|
|
filter_set_accel_config(filter, accel_config);
|
2015-07-31 12:29:23 +10:00
|
|
|
} else {
|
|
|
|
|
fprintf(stderr, "Invalid filter type %s\n", filter_type);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-19 16:19:27 +10:00
|
|
|
assert(filter != NULL);
|
2015-04-10 15:37:15 +10:00
|
|
|
filter_set_speed(filter, speed);
|
|
|
|
|
|
|
|
|
|
if (!isatty(STDIN_FILENO)) {
|
|
|
|
|
char buf[12];
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = SEQUENCE;
|
2015-04-10 15:37:15 +10:00
|
|
|
nevents = 0;
|
|
|
|
|
memset(custom_deltas, 0, sizeof(custom_deltas));
|
|
|
|
|
|
2025-07-01 16:30:11 +10:00
|
|
|
while (fgets(buf, sizeof(buf), stdin) && nevents < 1024) {
|
2015-04-10 15:37:15 +10:00
|
|
|
custom_deltas[nevents++] = strtod(buf, NULL);
|
|
|
|
|
}
|
|
|
|
|
} else if (optind < argc) {
|
2018-05-11 15:01:02 +10:00
|
|
|
mode = SEQUENCE;
|
2015-04-10 15:37:15 +10:00
|
|
|
nevents = 0;
|
|
|
|
|
memset(custom_deltas, 0, sizeof(custom_deltas));
|
|
|
|
|
while (optind < argc)
|
|
|
|
|
custom_deltas[nevents++] = strtod(argv[optind++], NULL);
|
2018-05-16 16:24:06 +10:00
|
|
|
} else if (mode == SEQUENCE) {
|
|
|
|
|
usage();
|
|
|
|
|
return 1;
|
2015-04-10 15:37:15 +10:00
|
|
|
}
|
|
|
|
|
|
2018-05-11 15:01:02 +10:00
|
|
|
switch (mode) {
|
|
|
|
|
case ACCEL:
|
2018-06-27 15:53:23 +10:00
|
|
|
print_accel_func(filter, profile, dpi);
|
2018-05-11 15:01:02 +10:00
|
|
|
break;
|
|
|
|
|
case DELTA:
|
2015-04-10 15:37:15 +10:00
|
|
|
print_ptraccel_deltas(filter, step);
|
2018-05-11 15:01:02 +10:00
|
|
|
break;
|
|
|
|
|
case MOTION:
|
2015-04-10 15:37:15 +10:00
|
|
|
print_ptraccel_movement(filter, nevents, max_dx, step);
|
2018-05-11 15:01:02 +10:00
|
|
|
break;
|
|
|
|
|
case SEQUENCE:
|
2015-04-10 15:37:15 +10:00
|
|
|
print_ptraccel_sequence(filter, nevents, custom_deltas);
|
2018-05-11 15:01:02 +10:00
|
|
|
break;
|
|
|
|
|
}
|
2015-04-10 15:37:15 +10:00
|
|
|
|
Introduce custom acceleration profile
The custom acceleration profile allow the user to define custom
acceleration functions for each movement type per device, giving
full control over accelerations behavior at different speeds.
This commit introduces 2 movement types which corresponds to the
2 profiles currently in use by libinput.
regular filter is Motion type.
constant filter is Fallback type.
This allows possible expansion of new movement types for the
different devices.
The custom pointer acceleration profile gives the user full control over the
acceleration behavior at different speeds.
The user needs to provide a custom acceleration function f(x) where
the x-axis is the device speed and the y-axis is the pointer speed.
The user should take into account the native device dpi and screen dpi in
order to achieve the desired behavior/feel of the acceleration.
The custom acceleration function is defined using n points which are spaced
uniformly along the x-axis, starting from 0 and continuing in constant steps.
There by the points defining the custom function are:
(0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1])
where f is a list of n unitless values defining the acceleration
factor for each velocity.
When a velocity value does not lie exactly on those points, a linear
interpolation of the two closest points will be calculated.
When a velocity value is greater than the max point defined, a linear
extrapolation of the two biggest points will be calculated.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2022-12-13 00:23:59 +02:00
|
|
|
libinput_config_accel_destroy(accel_config);
|
2015-04-10 15:37:15 +10:00
|
|
|
filter_destroy(filter);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|