The vast majority of ppl reading the README is unlikely to care about this,
but they do care about the Wayland vs X.Org situation so let's split this up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't required by doxygen but for a potential switch to RTD/sphinx
(see #95) it helps having this set up correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add some documentation for the most common quirks or at least the ones that
the user may eventually see or have to set. Drop the git commit hash into the
docs to make sure it's spelled out that the quirks are only valid for that
commit. Adding something with @include* requires the EXAMPLE_PATH to be set.
Doxygen doesn't parse markdown in @includedoc so we have to insert the commit
as normal HTML tag.
Related to https://gitlab.freedesktop.org/libinput/libinput/issues/87
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Doing so means we can ditch the specific input list for doxygen and just copy
all files over into our builddir/doc/ subdir, then use that subdirectory as
input data.
This relies on meson putting a subdir() into a subdirectory in the build
directory. This isn't technically guaranteed but I also suspect that if meson
ever changes that, lots of other projects will break. Even in that case we
should build just fine since we now filter for *.h and *.dox and don't copy
any other doxygen-commented files into the builddir anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Measuring the trackpoint range has not shown to be sufficient or precise
enough to be used as an ingredient for trackpoint acceleration. So let's just
switch back to a generic multiplier that we can apply to the input deltas do
undo any device-specific lack of scaling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gets rid of the trackpoint range propery that we've been parsing until
now and instead just opts for a basic curve with some deceleration for low
pressure. The speed range is taken from the touchpad and should be wide enough
for most trackpoints that fall within the expected range.
Trackpoints like the new ALPS ones need to be configured through a hwdb (this
part is currently missing).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The libinput/doc/latest is now built automatically from git, so it's good to
have a reference to show which commit it was being built from. Add a section
to the readme with git commit information that is replaced by meson.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Slightly more obvious than just "html". Main motivation here is that we want
to provide the documentation as artifact from GitLab's CI, so having it unzip
to something slightly more meaningful makes sense.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Enables us to easily add more tools where needed and it is
more consistent with the existing tools.
The commands are now:
libinput quirks list
libinput quirks validate
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/66
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, we had all extra device information ("This is an Apple Touchpad",
"This touchpad causes pointer jumps", etc.) in the udev hwdb. The problem with
the hwdb is that updating it is nontrivial for the average user and debugging
when things go wrong is even harder. Plus, the hwdb has a matching scheme that
is unpredictable unless one is familiar with the implementation.
This patch set moves the hwdb entries into .ini style text files, with a
simple line-based parser. A new libinput list-quirks tool can list the quirks
applied to any given device, in --verbose mode it prints all matches as they
apply or not apply.
The data files are currently unused by libinput, that comes in a later patch.
They're installed though, the defaults point to the /usr/share/libinput
directory and for *temporary* local overrides the single file
/etc/libinput/local-overrides.quirks.
Failure to parse any file is a hard failure for the quirks system, but if the
local override file doesn't exist that's fine.
THIS IS NOT A CONFIGURATION INTERFACE! None of these settings are exposed via
the libinput_device_config_* calls. There is no API guarantee for these files,
think of them as source code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The GitLab migrations means that bugs should now be reported there
rather than Bugzilla. Though the repository is still available via
anongit, cloning through GitLab allows use of HTTPS.
All freedesktop.org URLs are also preferentially served over HTTPS
rather than unsecured HTTP.
Signed-off-by: Daniel Stone <daniels@collabora.com>
On the off-chance that someone actually looks at this page, let's put the
comment most at risk by a TLDR attention span at the top.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems to give me roughly the same behaviour as macos does on the default
0 speed setting.
* Default speed is lower than before by around 30% [1]
* Acceleration kicks in much sooner (130mm/s vs 250mm/s before)
* Acceleration kicks in slower at lower speeds, so the change from 130mm/s to
150mm/s is less than that of 320mm/s to 350mm/s
* The effect of the speed setting is a wide-range constant (de|ac)celeration
[2], which means:
* The unaccelerated baseline up until the threshold now changes with the
speed setting
* The threshold is now the same for all speeds
* The range of the speed setting should now easily cover all desired device
speeds.
* Acceleration is steeper at higher speeds
* Deceleration was left as-is.
[1] This may or may not fix the jumping pointer issues caused by the previous
high defaults. When you have high default acceleration you move the finger
slower. This slow movement caused some touchpads (mostly seen on Lenovos) to
create pointer jumps. These weren't seen on synaptics previously because of a
combination of higher user finger speed (thus not triggering the bug) or just
not being as obvious (2px jump vs 10 px jump).
[2] The speed setting is actually a curve, the closer you get to 1.0 the more
difference you see between two different values. The curve's points are:
-1/0, 0/1, 1/5, so the resolution is closer for slow speeds. We still have
double resolution on the setting though so you'll find what you want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Well, I say "measure" but really at this point it just reads the
properties/axes and then does it's best to auto-generate a hwdb entry that
matches the user's hardware and sets a fuzz value on the device. Ideally this
reduces the number of hand-holding required in bugzillas. There are plenty of
things that can go wrong, so our fallback is still to throw up our hands and
point to the documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
