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>
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>
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
We have a two-stage behavior: by default, we do not delay any events but we
monitor timestamps. The first time a bouncing button is detected we switch to
debounce mode. From then on, release events are delayed slightly to check for
subsequent button events. If one occurs, the releas and press are filtered. If
none occurs, the release event is passed to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100057
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This will eventually feature the architecture diagrams, etc. But for now it's
mostly just a list of what will be and what won't be supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.
And add a new doc page to explain what is happening and how to fix it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a touch moves by more than 20mm within a single frame, reset the motion
history, effectively discarding the movement. This is a relatively common bug
and almost always needs a kernel fix, so add an explanatory page to the docs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
