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
The `X-GNOME-Bugzilla-*` entries were for use by bug-buddy, a GNOME 2
technology that's been gone for over a decade. These entries are
obsolete and can be removed from all desktop files.
The `X-GNOME-Settings-Panel` entry is also obsolete as far as I can
tell and only these panels had it in their desktop file: notifications,
sharing, sound and user-accounts. These entries can also be removed.
After removing the `X-GNOME-Bugzilla-*` entries, the desktop files have
no more variables in them. The meson `configure_file` step is therefor
pointless—there are no variables to configure. As such the
`*.desktop.in.in` files are renamed to `*.desktop.in` to reflect this
and `meson.build` files are modified to remove `configure_file` step.
When the "Automatic" mapping is chosen for a display-attached tablet device,
Mutter is in charge of applying the heuristics to map the tablet device to
its most likely attached display.
When that happens, the Wacom panel does not know better (or anything)
to show the calibration UI than picking a GdkMonitor and hoping for the
best.
To improve this situation, Mutter has been added a D-Bus interface so it
is possible to query it for the output that a tablet device is mapped to.
This commit adds the support for this interface, so that the Wacom panel
does know to pick the right GdkMonitor to fullscreen the calibration UI on.
If you did not know the Wacom Express Key Remote (or EKR for short),
let me introduce it to you:
https://estore.wacom.com/media/catalog/product/cache/fb4143a007ae6439deba9b18afd745f2/a/c/ack-411050_main_2.jpg
This is a hand-sized standalone pad device, meant to be used together
with drawing tablets, providing additional buttons and a touch sensitive
ring that can be mapped to actions and keypresses.
These pads were so far handled in GNOME, but in a very subtle manner.
As the EKR is implicitly paired to a tablet, it was possible to map
EKR buttons from the paired tablet once the pad OSD UI from GNOME
Shell was shown.
As this device basically just needs a "Map buttons" action to
configure it, it just didn't sit well in the older Settings UI,
it would get a separate page with just a lone button in there. So
its support has been kind of an easter egg so far.
But the new UI can indeed accomodate better a device that is neither
tablet nor stylus, and has few options. This commit adds the EKR
as a separate AdwPreferencesGroup.
