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.
When we bring a generic pen (serial 0) into proximity, the tool is initialized
as "generic" and mapped to the current tablet. This is then written out into
the keyfile, so we end up with something like:
[056a:00d1]
Styli=generic;
On the next g-c-c start the generic pen is pre-loaded from the keyfile but not
yet associated with the tablet. When the pen gets into proximity the
association was handled like a completely new pen, thus triggering a key file
entry again. Eventually, our styli list looked like this:
[056a:00d1]
Styli=generic;generic;generic;generic;generic;generic;
Fix this by remembering whether we freshly initialized the tool or whether it
was already known. Since we can only have one generic tool per tablet (because
we wouldn't notice the difference between two physical tools) we just skip the
write of the keyfile.
Fixes#313
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.
libgudev allocs a new GUdevDevice object for each event, so the pointer value
for the 'add' udev event differs from the one for the 'remove' event. If we
use the pointer value as hash table key, we'll never remove the device.
Switch to use the syspath of the device instead, that one is unique per
device.
Fixes#309
This is needed to access widgets to make the shell adaptive.
This also adds libhandy as a submodule and will make use of that version
if it isn't available otherwise.
Add initialize_dependencies() to factorize the dependecies
initialization functions for better readability as another dependency
to initialize will be added in a following commit.
The Thunderbolt panel warns about explicit_bzero() not being available
but never checked for it.
gnome-control-center/panels/thunderbolt/bolt-str.c: In function ‘bolt_erase_n’:
gnome-control-center/panels/thunderbolt/bolt-str.c:33:4: warning: #warning no explicit bzero, using fallback [-Wcpp]
#warning no explicit bzero, using fallback
^~~~~~~
Closes: #286
