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>
For the puck/lens cursor tool we need to artificially reduce proximity
detection. These tools are usually used in a relative mode (i.e. like a mouse)
and thus require lifting and resetting the tool multiple times to move across
the screen. The tablets' distance detection goes too far, requiring the user
to lift the device several cm on every move. This is uncomfortable.
Introduce an artificial distance threshold for the devices with the default
value taken from the X.Org wacom driver. If a tool is in proximity but outside
of this range, fake proximity events accordingly.
If a button was pressed while we were out of range we discard that event and
send it later when we enter proximity again.
This is the simple implementation that only takes one proximity out value (the
one from the wacom driver) and applies it to all. Those devices that support a
button/lens tool and have a different default threshold are well out of date.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
[rebased, tests updated for new axis percentage behavior (8d76734f)]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The only time we need this is on proximity in, so move it to where we handle
that to have better locality. And rather than looping through and checking
each bit, just memcpy the axis capabilities, because by definition they
represent the set of axes that can possibly change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This will be set when the tool comes into proximity later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Now that we don't provide an API anymore to access the absolute value of the
wheel and the axes are handled separately, we can safely store the wheel delta
in the normal axis array.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We know when one of the bits is set we need to send an event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We know when one of the bits is set we need to send an event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Process the axes explicitly, rather than having a loop that needs special
casing for most axes anyway. And since we do the axes one-by-one, we can use
the evdev axis code directly rather than the axis_to_evcode helper.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The wheel is the only one axis that has actual deltas, all others have
straightforward deltas that we don't need to care about, the caller can
calculate those where needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only the wheel has a discrete value, no need to keep arrays for a single
value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a tool wears out, it may have a pre-loaded pressure offset. In that case,
even when the tool is not physically in contact with the tablet surface it
will send pressure events.
Use automatic pressure offset detection, similar to what the X.Org wacom
driver does. On proximity-in, check the pressure and if the distance is above
50% of the range and the pressure is nonzero but below 20% of the range, use
that value as pressure offset.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Ping Cheng <pingc@wacom.com>
