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.
This went mistakenly missing in the recent UI updates. Since this
panel is still accessible through search despite tablet availability,
we should have a proper empty state view when moving to the panel
with no tablets available.
Fixes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1684
This should significantly simplify these panels, by not forcing
them to override GObject.constructed all the time. Most panels
were quite straightfoward.
Many part of this commit were made by Carlos
Garnacho <carlosg@gnome.org>
WIP wacom: Port to GTK4
Lots of stuff missing and probably broken.
wacom: Port CcDrawingArea input to gestures
We have a handy GtkGestureStylus to use here, which avoids direct
handling of GdkEvents.
wacom: Update current stylus tracking to GtkGestureStylus
Use the ::proximity signal to notice when we are being hovered with
a tablet stylus, and look up the tool from there.
This puts stylus/pad tracking on 2 separate levels. The CcWacomPanel
will look for styli, and treat them as "device leaders", adding a
CcWacomPage for them.
The CcWacomPage will then track the related pad, and update the
"Map buttons..." action visibility according to it.
This simplifies tablet page creation (eg. have it completed in one
step), and decouples the device grouping logic from CcWacomPanel,
which will be useful in future commits.
Make the panel class provide a cancellable that will be cancelled when the panel
is destroyed. Panel implementations can use this and not have to mangage the
cancellable themselves. Consolidate cases where panels had multiple cancellables
that were all being used for this behaviour.
The button/popover are meaningless if there's no device to test with. Set
it inactive (so the popover hides if visible) and set insensitive if no
devices are found.
This used to be done only if the stylus was "brand new", because pages for
previously known styli are added when the tablet is detected/plugged. There
are however situations where this may break: eg. the stylus was previously
known through a tablet that is not plugged ATM. The tool is however "not
new" so no UI is added for it.
We should try to add the stylus invariably on proximity, add_stylus_page()
ensures there is only one page per tool anyway.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/315
When the wacom driver handles the touch device, we get a tool id of 0x3. Let's
ignore that because we don't need a tool for the touch node.
Ideally we should be able to rely on the GDK tool type but that one is always
GDK_DEVICE_TOOL_TYPE_UNKNOWN see
https://gitlab.gnome.org/GNOME/gtk/merge_requests/453
A GTK bug (also fixed in that MR) prevents the tool id from updating.
Until that GTK bug is fixed the pen will only be detected if it is the first
event from this physical device. If the touch node sends an event before the
pen, the pen won't be detected.
The xf86-input-wacom driver doesn't use 0 for tools that do not have an id or
serials. Serials default to 1, and the tool id is either 0x2 for stylus or 0xa
for eraser, see xf86WacomDefs.h, the defines for STYLUS_DEVICE_ID and
ERASER_DEVICE_ID.
libwacom uses 0xfffff and 0xffffe for the generic pens and all the lookup code
we have in the panel is designed for a serial/tool id of 0. So let's just map
the wacom driver IDs to 0 at the only transition point between Gdk and our
panel.
No devices with serials 0 or hw ids 2/10 exist, so this shouldn't have side
effects. This only affects X + xf86-input-wacom.
Use GsdDeviceManager to monitor libwacom-supported tablets coming and
going. Hide the Wacom panel from the list when there's no supported
tablets plugged in.
There's much going on under the hood here:
- Styli and tablets are now in split views, as per the mockups.
- CcWacomDevice and CcWacomTool are now in use, with the subsequent
API use changes. Moreover, using these objects means using the
newer schemas in gsettings-desktop-schemas, so there had to be
changes in the settings we store too.
- We now use CcTabletToolMap, plus listen to tool proximity events,
populating the "Stylus" sub-pane with those.
Tablets have not always an eraser (most of the generic tablets like Huion,
UC-Logic, etc... don't). We should not reject such tablets.
Commit 54849a9 (wacom: Only the stylus and eraser tools need to exist)
mentioned that we were not sure about eraser, and I think we should not
assume one either.
To do so, we simply ignore the eraser xinput node and rely on
libwacom to actually provide the eraser information.
If the stylus does not have the eraser tip, we may fall in the
LAYOUT_OTHER case. We have a picture of a generic Wacom pen with an
eraser, and the leaders linking the widget to the picture are scrambled.
To prevent that, gray out the eraser pressure slider so that we do not
break the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=746117
Since GTK+ commit 05b1ea84b, this hint is used in GtkNotebook to add
a GTK_STYLE_CLASS_FRAME when rendering the notebook frame, so the theme
renders those frame-alike. As it's not what we want for the wacom panel,
set show-border to FALSE on all GtkNotebooks.
https://bugzilla.gnome.org/show_bug.cgi?id=710709
Make it possible for panels to go all the way to the edge of the
shell. This is particularly important for panels that scroll, such
as the new power panel. All other panels are changed to compensate
for the loss of external padding.
https://bugzilla.gnome.org/show_bug.cgi?id=691229
This makes loading faster, with less I/O, avoids unnecessary
code duplication (around 1k lines shaved), and ensures that
all the panels link and work appropriately.
By the same token, it will stop external panels from being
created, and loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=690036
The device_added_cb is called once for each tool added. The wacom driver
hotplugs tools in the order stylus, eraser, cursor, pad.
update_current_page will add a new page once a tablet has stylus and
eraser, before cursor and pad exist. priv->pad is thus always NULL,
causing, cc_wacom_page's update_tablet_ui to remove the "Map Buttons..."
button for any device.
Change the code to update the tool list for every new tool we get,
merely triggering the visibility of the button instead of destroying it
completely.
https://bugzilla.gnome.org/show_bug.cgi?id=672691
Pages are now created dynamically, and the UI supports multiple
different types of tablets (even though GsdWacomDevice doesn't, and
we don't have any UI to switch devices).
