Previously we'd only allow calibration if the "Automatic" monitor
mapping was selected. In cases where that fails (happens here with a
Kamvas 12 connected to a laptop) we need to select the monitor mapping
manually - but we shouldn't lose the ability to calibrate.
So make this dependent on whether the device is a tablet built into a
display.
Otherwise we could calibrate the device to be upside down by doing a
reverse Z (starting lower-right). If the device is mounted upside-down
this should be fixed elsewhere.
Our along_axis() helper would compare the input value against both x and
y of the reference point. This can lead to misdetections of the distance
to the desired points, e.g. if the upper-left reference point is 100/100
and the upper-right point is a clearly-wrong 99/2500, the alignment
would succeed because the x-axis is within the threshold.
This would sort itself out later since the lower points are difficult to
get right then, but let's fix this by checking the desired alignment
only. This way a misclick happens on the actual misclick, not on the
next point(s) in the sequence.
The code was written to (sort-of) accomodate for the four calibration
points to happen in any sequence. Except we don't care about that, we do
it in a Z shape starting top-left - so let's simplify the code to check
for that sequence.
For anyone calibrating the tablet the threshold doesn't really matter,
it's in their own interest to be as precise as possible. Meanwhile, for
testing a larger threshold makes life a lot easier as we don't need to
be that exact to go through the calibration sequence.
Finally, for devices with calibration seriously out of whack a larger
threshold allows those devices to be used.
Whether libwacom knows about a tablet has no effect on whether the
tablet works, only whether we know how to map it, which styli are
available, etc.
Instead of pretending there is no tablet connected let's use the
libwacom fallback tablet instead. As of libwacom 2.11 that defaults to a
built-in tablet (the vast majority of devices these days) which means we
can at least map this to an output, calibrate it etc.
Remove the gnome_rr_* bindings and substitute them with the respective
calls from the CcDisplayMonitor. This way we get the same monitor names
as the display panel.
Closes#1821
This fixes an error when building with `-Werror=maybe-uninitialized`.
It’s a false positive, because the `for` loop conditions ensure that a
`default:` case in the `switch` is never needed. However, compilers are
historically quite bad at static analysis of loop iteration count, so
let’s just initialise the variable to a safe default.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
