Now that we have a wiki page let's link to it, it has all the details
on how and why we (plan to) do this.
Also change the wording to be make it easier to anthropomorphize bugbot
when it adds that comment, ideally leading to fewer grumpy users.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1093>
We have labels like needinfo or triage needed but all these labels
require intervention from a privileged user - normal users cannot
set labels on a project.
The only thing users can all do is open/close/re-open bugs. So let's try
to incorporate this into our event flow: if we need something from the
user we ask for it, close the bug and when the user supplies this
information they can re-open it. This means e.g. bugs waiting forever in
triage will not show up as actionable in the issue list.
Since users aren't used to that workflow let's add a bugbot blurb that
explains that we're not really closing the issue, just using that as the
only lever we have available.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1090>
If we get to SWIPE_START we send out the BEGIN event and transition to
state SWIPE. We must not process that state immediately to avoid sending
out a spurious UPDATE event when nothing has changed.
Same for the PINCH_START/PINCH and SCROLL_START/SCROLL states.
This also fixes a crasher where we end up with NaN in the custom
acceleration function because passing the same timestamp in twice causes
a division by zero (delta time is zero).
Closes#1053
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1088>
There appears to be a race condition where an ABS_MT_TRACKING_ID -1
event is on the wire but libevdev_fetch_slot_value() for that slot
already gives us -1 as well.
If we just (re)opened our device, synching our slots would thus set zero
active slots and then trigger the assert when that event is being
processed.
It's unclear how to reliably reproduce this issue but removing the
assert and simply ignoring this event if we don't have active slots
is correct anyway.
Closes#1050
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1081>
Follow commit 65b53f82ff ("quirks: lower AttrTrackpointMultiplier for
ThinkPad X200/201 to 0.25") and lower this multiplier for Lenovo ThinkPad
X200s/201s models, as I found the identical issue as the one previously
quirked for ThinkPad X200/201.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1084>
Upstream commit 43cd2cbf83 ("data: add the dell trackpoint multipliers")
broke the default acceleration profile on Lenovo ThinkPad X200/201, where
the cursor speeds became so quick that it was practically impossible to
control. Merely dragging on the TrackPoint lightly would result in the
cursor flying from corner-to-corner.
I have tested on a Lenovo ThinkPad X201 to find
`AttrTrackpointMultiplier=0.25' the most reasonable and closest to the
default behaviour on Windows 7 with Lenovo's driver.
Not sure about ThinkPad X200s/201s, but I suspect that they would have
similar issues (with the multiplier set to 1.25). I have just ordered both
models to experiment with and will report back with another patch if I
find similar issue.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1080>
Some Lenovo ThinkBook 14 G7+ ASP models ship with pressure pads (nominally
"Force Pad"). However, they do not appear to be declared as such by the
firmware.
Add a quirk to make them work.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1079>
If a tablet has an area configured and the pen goes into proximity
outside this area, ignore all events from this sequence. This truly
deactivates that area so it can even be used for e.g. placing a pen
there.
For simplicity, a sequence that starts outside the configured area will
be completely ignored, i.e. moving into the tablet area will not trigger
any fake proximity events as we cross into the allowed area. This
requires quite a bit of effort and it's unclear if it's really needed by
users - we can reconsider when we get complaints.
We do however accept a proximity event within within 3% of the
configured area. This gives us 6mm on a 200mm tablet where we can move
in from the area and still have events work, i.e. some error margin for
where a user needs both an area and work closes to the edge of that
area.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
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>
This test does a prox in/out and immediately drains events.
Where we are slow enough we may drain only one (or none) of the
proximity events which causes a failure later in the test.
Similar issue with the second test where we may get a delayed tip event.
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>
Since our implementation uses the sysfs LED files and we don't have
those, all our test devices have the single fallback mode and no
more. Add a comment to all these tests to make that clear and enforce a
single mode only so it's more obvious.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1070>
