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>
If we have pressure but not BTN_TOUCH, force the pressure to 0. Otherwise,
force distance to 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Keep pressure and distance mutually exclusive regardless which one of the two
updates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If it's a finger, it's a touchscreen or a touchpad, not a tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Behavior for axis events in the same event frame as the BTN_TOUCH is to
always send axis events before any tip state.
Behavior for button events in the same event frame as the BTN_TOUCH is to
order button events to happen when the tip is in proximity, i.e. after the tip
event on tip down and before the tip event on tip up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
