Support changing the mouse and trackball acceleration profile. This
makes it possible to for example disable pointer acceleration by
choosing the 'flat' profile.
This adds an optional dependency on gudev. Gudev is used by the X11
backend to detect whether a device is a mouse or not. Without gudev
support, the accel profile settings has have effect for mouse devices.
Trackball still uses the "strstr" approach, since udev doesn't support
tagging devices as trackball devices yet.
https://bugzilla.gnome.org/show_bug.cgi?id=769179
Add support for setting edge-scrolling separately from two-finger
scrolling. We now have 2 separate boolean settings for those, with the
Mouse panel in gnome-control-center allowing to set only one of those at
a time, but nothing precludes both being set in the configuration.
We need to handle:
- two-finger-scrolling-enabled and edge-scrolling-enabled settings both
being set.
- those 2 settings being change out-of-order
- two-finger-scrolling being set on a device that doesn't support it
- edge-scrolling-enabled on a device that doesn't support it
And the combinations of one touchpad supporting just one of edge
scrolling and two-finger scrolling and another vice-versa.
https://bugzilla.gnome.org/show_bug.cgi?id=768245
Instead of continuing eventually crashing with a segmentation fault due
to a missing renderer, make MetaBackend an GInitable, and gracefully
handle the failure to fully create the backend with an EXIT_FAILURE.
https://bugzilla.gnome.org/show_bug.cgi?id=769036
We only use a handful of the attributes set, so lets stop pretending
that things are initialized for a reason. Eventually we should stop
using XWindowAttributes in the generic MetaWindow creation path.
https://bugzilla.gnome.org/show_bug.cgi?id=769070
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.
