If the compiler cannot figure out that the condition for setting
the dev variable is the same as the condition for accessing it,
it will complain about potential uninitialized use.
We must lookup the mode switch serial for the group where the button
belongs to. Also, avoid the changes if the client requests setting
the feedback for buttons owned by the compositor.
We assumed that each group could only have 1 strip and/or ring, because
accounting is performed per group, so we could not assume the real
index for anything above 1. Get rid of this restriction, now that
MetaWaylandTabletPad does its own accounting of rings/strips, alongside
groups.
This is best for 2 reasons:
- It's feels cleaner doing first creation of rings/strips and then
the group assignment. The other option is making groups iterate
other all rings/strips and selectively skip those not meant for
it, which sounds somewhat redundant.
- Some minimal accounting of rings/strips without group restrictions
is needed for meta_wayland_tablet_pad_get_label().
The rings/strips memory is now owned by MetaWaylandTabletPad instead
of groups, which is sort of meaningless since all are meant to go
at the same time.
There may be external/compositor-specific reasons to trigger the
pad OSD. Expose this call so the pad OSD can be triggered looking
up the right settings, monitor, etc...
This API will be used from the gnome-shell pad OSD implementation, in order
to show the actions that currently apply to every button/ring/strip in the
tablet.
It does nothing at the moment, but can be hooked into MetaWaylandTabletPad
now. For X11, we need to trigger these for the pad events we receive from
the passive pad button grabs.
This function will be useful for the wayland implementation, because buttons
are mapped at the time of sending those through the wire.
As x11/wayland implementations differ here, this function will be useful for
the wayland implementation, as the action is handled lat
Some settings make no sense on external tablets, and others make
no sense in display/system-integrated tablets. Perform those checks
so we don't end up with possibly broken configuration.
Depending on clutter_input_device_get_mapping(), or whether the current
tool is either cursor or lens (those don't make any sense in absolute
mode), relative motions will be reported.
This function call only applies to tablets, and thus will error
out unless it's called with CLUTTER_TABLET_DEVICEs. This will
allow setting absolute/relative mapping on those on the fly, as
this is optional.
Given that information defines largely how such devices are to be
configured, it makes sense to have that information at hand. A getter
has been also added for the places where it could be useful, although
it will require HAVE_LIBWACOM checks in callers too.
