The tablet axis struct has a delta field that's only useful for the events,
not for our internal axis handling. Make sure we never set it to anything
nonzero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
Handle the delta in the end once we've updated the device state for all axes.
This requires us to use the device history rather than the current state
delta, and it also requires us to update both x and y whenever an axis change
comes in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
This is a bit hard to follow:
- tilt is handled first and if either tilt axis is set we fetch *both* tilt axes
into tablet->axes.tilt
- rotation is handled second but it only triggers if either tilt axis is
flagged. as we now guarantee to have both axes in tablet->axes.tilt, we
can continue with the rotation conversion without needing some other state
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
This is prep work for axis smoothing. Modify the various helper functions to
just update the state in the tablet and then grab the state later for better
grouping.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
No functional changes, part of the grouping of tablet axis manipulation vs.
processing of that manipulated state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
No functional changes, this is just to group the calls that modify tablet axis
state together and move the bits that rely on this state (but don't modify it)
to the bottom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
Stores the processed axes values in a history 4 events deep. Currently unused
but will be used to smoothen out axis values to avoid transducer-caused axis
wobbles.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
The current code modifies a bit of state inside the proximity_tip_down
function which makes for confusing reading. Clean this up by having a bunch of
helper functions for the various events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
This cannot trigger because we'd never get here if out-of-proximity is set,
tablet_flush() will return early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
The only code path that leads here would see the changed_axes array zeroed out
in tablet_send_axis_proximity_tip_down_events(), zeroing again is unlikely to
make it more zero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
Prefix device log messages with the device's sysname so it's more obvious
where the messages are coming from. This makes it much easier to grep for a
specific device's messages but also adds some identifier to messages that
were previously without any identifier (e.g. all the state machine debugging)
All info and error messages also automatically prefix the device name, so
those messages are standardised too, e.g
an info message now:
event4 - SynPS/2 Synaptics TouchPad: is tagged by udev as: Touchpad
a debug message now:
event4 - using pressure-based touch detection
And since this required changing a lot of the strings in messages anyway,
polish a few minor things too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Set the dispatch type on creation, then check that whenever we try to get the
dispatch struct. This avoids a potential mismatch between the backends.
Plus, use of container_of means we're not dependent on the exact layout
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Fix the kernel driver or get a udev override in place. Tablets not having a
physical size is not ok.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.
In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.
Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
If a tool starts reporting with serial 0 and later updates to a real serial,
discard that serial and keep reporting as serial 0. We cannot really change
the tool after proximity in as we don't know when callers query for the serial
(well, we could know but any well-written caller will ask for the serial on
the proximity in event, so what's the point).
Thus if we do get a serial in and the matching tool, check if we have a tool
with the serial 0 already. If so, re-use that. This means we lose correct tool
tracking on such tablets but so far these seem to only be on devices where the
use of multiple tools is unlikely.
https://bugs.freedesktop.org/show_bug.cgi?id=97526
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The Logitech MX master has different click angles for the two wheels.
https://github.com/systemd/systemd/issues/3947
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All these effectively returned bools anyway, switch the signature over to be
less ambiguous.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
These are internal functions, if we need them to return an error code we can
change that at any time. Meanwhile, if we only ever return 0 anyway we might
as well just make them voids to save on error paths.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The current code tried to emulate the relative motion to be equivalent to the
absolute motion, except in screen coordinates. This is way too slow for the
cursor tool that we want to behave like a mouse.
Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
motion is way too fast to be usable. Scale it down to match a 1000dpi device
instead. Since the cursor and lens tool are still high precision devices leave
them in a flat acceleration profile without actual acceleration.
For the stylus-like devices leave the current accel, pointer acceleration on a
stylus is hard to handle.
This also adds the missing bits for actually using the speed factor set
through the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
And change the various callers, especially those where we only had the
separate struct for indentation purposes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
25a9f39 changed the range to [-1, 1] but that's incorrect for the distance
values. Split the normalization up into two functions and make sure our
distance range is correct.
https://bugs.freedesktop.org/show_bug.cgi?id=95074
And while we're at it, sneak in a test for pressure ranges too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
This is especially a problem for the cursor tool which can be legitimately
left on the tablet. It wobbles by a couple of device units, resulting in
continuous axis updates to the caller. Pre-filter any of these events by the
axis' fuzz value so we don't even process them.
For ABS_DISTANCE which doesn't have a fuzz we hard-code a minimum fuzz of 2.
This should eventually land in the kernel though.
https://bugs.freedesktop.org/show_bug.cgi?id=94892
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Supposed to be [-1, 1] but we only generated [0, 1]
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Carlos Garnacho <carlosg@gnome.org>
The HUION 580 has a "consumer control" event node that has an ABS_VOLUME, keys
and a REL_HWHEEL. It has the same VID/PID as the pen tablet and libwacom
labels it as ID_INPUT_TABLET. This causes a crash later when we try to init
pointer acceleration for a device that doesn't have axes.
https://bugzilla.redhat.com/show_bug.cgi?id=1314955
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A nonzero resolution on the tilt axes is units/rad so we can calculate the
physical min/max based. Uneven min/max ranges are supported.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
If the tablet is already in proximity on startup, we used to immediately sent
a proximity event. We can't fetch MSC_SERIAL from the kernel, so that tool
always had a serial of 0, followed by events with the real serial. Since
clients are supposed to use the serial for the tracking of tools, this is
suboptimal.
When the tablet is added, merely set the internal proximity flags. This way we
wait until the first real event from the device (which includes the serial
number) and convert that into a proximity event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom tilt range is 64 degrees so we map everything into that until we
know otherwise.
This commit also switches the tilt axes around to align the angles with the
x/y orientation, i.e. tilting the top of the stylus towards the positive x
axis now generates a positive x tilt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Makes the code less generic, but more expressive. No visible functional
changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
When we're only dealing with BTN_TOUCH we can make the tip event independent
of the axis event. Now that we handle pressure thresholds to trigger tip state
this does not work, we'd have to send an axis event with the new pressure and
then a tip event. Since the pressure triggers the tip event this seems
disconnected.
Make the tip event officially capable of carrying axes. A caller can then
decide how to forward this to the next layer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
On tablets with ABS_PRESSURE use a pressure value to determine tip state, not
BTN_TOUCH. This enables us (down the road) to have device-specific pressure
thresholds. For now we use a 5% default for all devices.
The threshold is a range, if we go past the upper range we initiate the tip
down, if we go below the lower range we release the tip again.
This affects two current tests:
* Once we have pressure offsets and pressure thresholds, we're biased towards
pressure. So we can only check that distance is zero when there is a pressure
value, not the other way round.
* When the pressure threshold is exceeded on proximity in with a nonzero
distance, we can only warn and handle the pressure as normal. Since this is a
niche case anyway anything fancier is likely unnecessary.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Makes it even longer, but at least it's consistent with button and key state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
