For external tablets like the Intuos series we now expose the area
rectangle configuration and the (minimum) implementation required to
make this work.
Because an area configuration may apply late and tablet events usually
get scaled by the compositor we need to store the current axis extents
in each event. This is to behave correctly in this events sequence:
1. tool proximity in
2. caller changes config, config is pending
3. tool moves, generates events
4. tool goes out of prox, new config applies
5. caller processes motion events from step 3
If the caller in step five uses any of the get_x_transformed calls these
need to be scaled relative to the original area, not the one set in
step 2.
The current implementation merely clips into the area so moving a stylus
outside the area will be equivalent to moving it along the respective
edge of the area. It's not a true dead zone yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
This adds the configuration option to define a rectangle that serves as
an input area on external tablets such as an Intuos.
The intention behind this is to make this input area behave as if it was
the only physical input area on this tablet with libinput emulating
proximity events as required for where the tools moves in and out
of this area.
This could also be achieved with the existing calibration setting but
area configuration is not calibration and we don't want to expose other
side-effects of the matrix (e.g. scaling and rotation) for these
devices.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
device->abs.absinfo_x/y points to the x/y axis we want to use and
that axis is used in all the evdev helper function. For consistency
use that one here too.
This is for consistency only and has no effect on tablet devices, the
only time this isn't ABS_X/Y is on multitouch devices where that points to
ABS_MT_POSITION_X/Y.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
The vast majority of devices that libwacom doesn't know about are the
various built-in ones. Since the only effect in our code here is that we
enable the calibration matrix, let's default to built-in if we don't
know any better - better to have the matrix and not use it than to not
be able to calibrate a tablet.
Note that libwacom 2.11 and later also now default to a built-in tablet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1074>
Instead of re-creating the the libwacom device from the database every
time we need it let's create it once during tablet|pad_init and pass it
down to the functions.
This allows us to have one point per tablet/pad where we can log an
error if the device is not supported by libwacom - previously this was
printed during the left-handed setup.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1073>
This was historically based on the LEDs on the device: we'd loop through
the LEDs and assign them to pad mode groups, then figure out which
button is the mode toggle for that group and finally which buttons
are in the same position as that toggle button.
Devices like the XP Pen ACK05 Remote don't have LEDs though but they do
have a mode toggle button [1] inside the dial. Let's support those by
switching the initialization on its head: search for mode toggle
buttons, create a mode group per toggle button, then associate
LEDs with that group.
The outcome should be functionally the same for devices with LEDs but
allows us to create mode groups where no LEDs exist.
Closes#1045
[1] As per Windows default button behavior
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1070>
This prevents accidentally leaving the fd set after closing.
And it includes the -1 check so we don't need this everywhere ourselves
(not that we use it right now but valgrind likes to complain about
this).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
Since our API doesn't accomodate for "dunno" we need to pick a mode that
we are actually in. This happens on the Intuos Pro 2 (PTH-660) which has
all LEDs on brightness zero, resulting in a failure to set up the modes
and we're left without a mode button.
Fix it by just picking zero as the default mode until specified
otherwise.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1069>
These events aren't used to signal scroll/swipe/pinch/..., merely to
signal the start of that gesture. So let's rename it to make the code
clearer (e.g. why do we log a bug when for a FOO event when we're in
state FOO?).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
Confusingly, tp_gesture_handle_state() would do almost nothing with our
state machine and the various tp_gesture_handle_state_foo() were called
later from tp_gesture_post_gesture().
Rename those functions into so that we have
tp_gesture_update_finger_state() first followed by
tp_gesture_handle_state() which is responsible for dealing with the
state machine.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
This allows for a slight optimization of the quirks parser: where
multiple devices from the same vendor require the same quirk, allow
for multiple product matches in the form:
MatchProduct=0x0001;0x0002;
This is stored as a fixed-sized zero-terminated array - a product ID of
zero isn't something we need to worry about in real situations.
Closes#879
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1038>
The two high-res axes should already be scaled appropriately by the
kernel. This unnecessary scale factor causes 1 click of the dial to
produce an event delta of +-14400 rather than the expected +-120.
Fixes: beca998122 ("tablet: add API for relative dials")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1029>
