Otherwise we just return the first output with the corresponding vendor
and serial number.
Fixes: 75ce02e202 ("wacom: Provide connector name for disambiguation")
Unlike tip erasers, styli with eraser buttons (which is the vast
majority anyway) have the same tool ID as the pen so the first
matching stylus we find is the right one.
This avoid a warning when a AES stylus is connected - we're constructing
the stylus based on our cache information which is just ID and serial
but no device - meaning the device lookup cannot work.
Fixes: 42b39cb956 ("wacom: Prefer the stylus over the eraser")
These are styli like the Dell Active Pen and most of the styli supplied
with laptops with built-in tablets. We don't always know how many
buttons these have so the SVG has just one large button. They're
typicall slimmer and less rounded than the Wacom pens so let's reflect
this here too.
This requires libwacom 1.4 released June 2020
The calibrator gets a GdkDevice from the GtkGesture but that device is
the "Logical device for $TABLET", not the actual device. So all our
clicks are discarded as coming from the wrong device.
Fix this by passing the GsdDevice through and comparing against that.
Closes#1871
Provide the connector name as the fourth value in the
tablet's output setting. With recent Mutter, this will
allow disambiguating the mapped output if there happens
to be multiple outputs with the same EDID data.
Pad and tablet grouping has become more irrelevant to the
Settings UI since commit 39402f21ba, as the EKR is the only
known case of an additional pad with distinct vendor/product
that is tied to another device.
But we preserved the grouping of pads (for the tablet EKRs
get paired with), thus possibly still requesting the pad OSD
to be shown on one of these arbitrarily.
In order to ensure that each "Map Buttons..." button in the
UI goes to the right pad being mapped, drop this grouping of
tablets, and make a CcWacomPage only observe a stylus/pad
pair in the same group (i.e. belonging to the same device, if
multiple similar ones are plugged) and with the same vendor+product
(i.e. coming from the same device).
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2876
libwacom_has_eraser tells us if this non-eraser tool has an
associated eraser (same serial, different tool id)
libwacom_is_eraser tells us if the current tool is an eraser device.
Now that we always have the stylus for the tool in proximity (see the
previous commit), switch this back to the has_eraser function and
rename it in the process so it's more obviously not the seemingly
obvious interpretation.
This reverts commit 9bd0b94527.
Pens with an integrated eraser share the serial number with the
corresponding pen but differ in the tool ID. libwacom provides a
"paired_id" mapping to look up one from the other.
If the user brings the eraser into proximity the very first time the
tool is seen, the eraser's tool ID is stored in the keyfile instead of
the associated stylus id. This leads to otherwise wrong behavior since
erasers share the serial number with the stylus but don't have any
buttons, don't have any erasers themselves, etc.
Fix this by looking up a matching stylus when we see an eraser. This
effectively filters our CcWacomTool to always be the pen, which is an
inadvertent assumption anyway.
The overwhelmingly vast majority of users will never see anything else
than a "Standard" (i.e. pen-shaped) stylus. And there's a mismatch
between e.g. the Pro Pen 3 being labeled as "Standard stylus" when users
spent money on getting a Pro pen.
Let's drop the "Standard" prefix, it adds nothing in this context.
Now that our first and last configuration points are 0/100 and 100/0
respectively, we can simplify the calculation a bit. Doubly so because
p2 is just a mirror of p1.
That with extending the slider range to 200 means we get a value for
each integer combination on our pressurecurves - which in turn means
that for any of our generated curves we get a slider value return.
Our previously hardcoded pressurecurves follow a predictable
pattern so we can generate the value on-the-fly based on that pattern.
The slider now uses a range of 100 (integer) values and calculates the
matching pressure curve based on that. The actual pressure curve remains
the same for previous values.
However, the functions are lossy thanks to CLAMP() so figuring out
a slider position from points requires heuristics: for each of the four
coordinates we calculate a slider value. Then we calculate the points
for that slider value and if those calculated points match ours then we
have a winner.
There's only one device like this that we support so we might as well
use its name as-is instead of a more confusing "External Pad device"
which isn't very descriptive unless you work with tablets and know what
a "pad" is in this context.
Anyone who owns this device will have bought it under the name
ExpressKey remote.
Fixes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2044
The method gtk_widget_translate_coordinates is deprecated in gtk 4.12.
Use a new method gtk_widget_compute_point instead.
general: Apply suggestions graphene point
Meson extracts them by itself and add them as dependencies for the target.
It means one less location to keep track of files, and a lot less boilerplate
around the meson files
