Print the type of event when it is queued up internally. This makes it a lot
easier to associate evdev events with the libinput event queued up and does
not depend on the caller calling libinput_dispatch().
Since this should only be used during development, hide it behind an if 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
For checking if a tablet tool can be uniquely identified by libinput. In
practice this means checking for a nonzero serial number, but let's not
restrict ourselves to allowing just that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
Internally we still use it, at least for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Only the rel wheel has true delta events, everything else is a delta
calculated by libinput based on the previous position. Since we supply that
position to the callers anyway, they can determine that delta themselves
where needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Note that this commit drops the ability to check whether a tablet has an x or
y axis. If it doesn't, libinput won't initialize the tablet anyway so this was
superfluous already.
Likewise with the tilt axes - either we have x and y tilt or we have neither,
so separate checks for tilt_x and tilt_y is unnecessary.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Second part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Note that this commit drops the ability to get the absolute value from a
relative wheel. The previous API always returned 0 for this case, it is not
needed anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@redhat.com>
First part of the big revamp to get rid of libinput_tablet_tool_axis and
replace it with a set of axis-specific APIs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Lyude <cpaul@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 an x220 is updated to the touchpad firmware version 8.1, the touchpad
suffers from the same issues as the x230 and needs custom acceleration code.
Unfortunately we cannot detect this otherwise, so it is left to the user as a
custom hwdb setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1264453
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Once we trigger diagonal scrolling, the device's scroll direction is set as
horiz+vert. From then on, both axes will be set on every subsequent scroll
event, even when the actual delta for an axis is 0.
This causes continuous scroll stop events in clients that care about these
things.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.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 all fingers are released in the same frame, we won't be able to find the
top-most touch.
https://bugs.freedesktop.org/show_bug.cgi?id=93204
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These aren't real button events and they are handled elsewhere, either through
proper touch events on touchscreen or through custom handling in the touchpad
case.
https://bugs.freedesktop.org/show_bug.cgi?id=93165
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>
