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
The airbrush tool has only one button, and the button mapping combo box
does not work.
We should not bail out if the widget has been removed, that means that
the stylus does not support the second button.
Check upfront the number of buttons to know if the top button parameter
is available.
https://bugzilla.gnome.org/show_bug.cgi?id=746263
GsdWacomDevice has been updated, dragging GsdDeviceManager as a dependency
from g-s-d, which has been added to panels/common, and compiled as a
separate static libary, which is used by the wacom and mouse modules.
gsd-input-helper.[ch] is now in such library and has been removed from
the panel directories.
https://bugzilla.gnome.org/show_bug.cgi?id=743196
The previous axis swapping code would oddly rely on the input coordinates
remaining on untransformed device coordinates, while those are gotten on
screen coordinates (hence rotated), this would cause swapping not to kick
in, and result in swapped X/Y scaling to be applied to X/Y ranges.
So make the axis swapping code be calculated upon screen coordinates, as
the collected points already are, and swap the applied scalings if
necessary.
Also, the code that swapped coordinates before returning to the caller
would scramble min/max values when swapping x/y. Fix that too, minimum
and maximum should stay like that when swapping axes.
https://bugzilla.gnome.org/show_bug.cgi?id=732442
This is deprecated in newer automake versions, and this causes warnings
with automake 1.14:
panels/printers/Makefile.am:3: warning: 'INCLUDES' is the old name for
AM_CPPFLAGS' (or '*_CPPFLAGS')
https://bugzilla.gnome.org/show_bug.cgi?id=732189
The "target" was seen moving from 0,0 to the first calibration
point, so 1) avoid target relayouts when the window is still
being positioned and 2) start the "target" actor as hidden so
it isn't seen moving from anywhere when first shown.
https://bugzilla.gnome.org/show_bug.cgi?id=719698
Keep the reference for the error/helper messages animations in
the CalibArea struct, so those are destroyed and not leaked, or
possibly crashing when running on already destroyed actors if
the dialog gets cancelled at the right time.
https://bugzilla.gnome.org/show_bug.cgi?id=719698
Calibration must be performed based on the device w/h ranges and the
screen size, so in which coordinates the monitor is virtually mapped
matters little on device coordinates. This fixes calibration of devices
attached to a monitor elsewhere than (0,0) in the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=719574
the actor's draw() method isn't guaranteed to get a pristine surface,
which may cause artifacts if the background is left untouched, so
clear the background each time the actor has to be drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=719701
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
The calibration gui code moved the targets to x,y, instead of
placing the centre of the target at x,y, leading to a 47 pixel
(half the target's size) offset in both directions (thus 67 pixels
deviation as Pythagorus would tell us).
We shouldn't be using the old calibration values to create the
new ones, so reset the "area" settings before starting a new
calibration, and re-apply the saved calibration if the calibration
is cancelled or fails.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
We were always getting the events from the core pointer instead
of the device itself, so threw all of them away.
We need to get the real source device from the event.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
We receive ClutterEvents, not GdkEvents for button presses on
ClutterActors, so use the correct functions to filter devices.
This also fixes the offset used to access the coordinates of the
events. We were actually using the pointer to the source and x
struct members instead of x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
GnomeRR now returns the EDID IDs as strings directly, so we don't
need to convert them to compare to the settings. Also, we don't
need to filter disconnected outputs, it's done by mutter now.
https://bugzilla.gnome.org/show_bug.cgi?id=705573
