As whether edge scrolling is enabled depends on whether two-finger
scrolling is disabled, make sure to update two-finger scrolling first.
Note that this only fixes the problem on startup. Changing the
settings in GSettings directly might cause an inconsistent state, but
the main UI for this setting, gnome-control-center, makes sure to
update two-finger scrolling before edge scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=769276
An empty argument list means "unspecified arguments", and not
"no arguments" like it does in C++. If an implementer of Mutter
plugins uses gcc -Wold-style-definition, as configured by
AX_COMPILER_FLAGS_CFLAGS, they will get warnings about this.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Florian Müllner <fmuellner@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=769971
The scale will have been set to 1 no matter what when initializing the
MetaOutput since it at the time didn't have an CRTC assigned to it.
Now, when we assign the CRTC to the output, we need to update the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=769505
We do some things when binding to a socket fails (closing the fd,
logging, unlinking files, ...) those might affect errno in some
or other way, so it might no longer be EADDRINUSE even if we later
try to make those non fatal.
It seems better to check errno soon after the failure, and don't
rely on it in any way at a later point. All error paths in
bind_to_abstract_socket() also have early logging, which also might
help figure out better the point of failure when the socket fails
to be created.
https://bugzilla.gnome.org/show_bug.cgi?id=769578
Allocate the offscreen stage view framebuffers up front; otherwise they
may get allocated after the viewport calculated by the stage is set,
which would cause the viewport to be incorrect until recalculated.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
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.
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.
All pads will share the same focus than the keyboard, so this means that:
- The focus changes in-sync for keyboard and all pad devices, and
- Newly plugged pads will be immediately focused on that same surface
This object represents the collection of buttons, strips and rings
in a tablet pad. All the objects created (pad, strips and rings)
share a common focus surface and have the same lifetime.
This is now separated from the generic cursor one. This means that wl_surfaces
can't be shared across wl_pointer and wp_tablet_tool. This is a change in
tablet protocol v2.
This is a simple subclass of MetaWaylandSurfaceRoleCursor, mostly
so we can distinguish by GType, the methods in the parent class
still apply and are useful.
When launching a GNOME session from a text-mode VT, the logind session
type is unlikely to be set to either "wayland" or "x11". We search for a
supported session type first with logind and then with
$XDG_SESSION_TYPE. As a fallback, we also test $DISPLAY in case of a
"tty" logind session to support starting through xinit. Ideally, such
setups should set XDG_SESSION_TYPE=x11.
If no supported session type is found, we throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=759388
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
By creating a pending gbm/EGL surface pair, only setting it on
swap-buffers, we would draw onto a buffer on the old surface, then swap
the buffer from the new surface, causing the first frame after a
hot-plug always having no content.
This was in the past not very noticable since some non-deterministic but
frequent side effect in gnome-shell caused hot-plugging to always render
two new frames, but after "Introduce regional stage rendering", this
side effect did not occur as often, thus making it more visible.
This commit updates the current gbm/EGL surface pair before painting a
frame, so that when the frame is painted, the surface with the correct
size is used and the buffer from correct surface is swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Being a listener to a signal, it is inconvenient to enforce order of
execution between different signal listeners. If there are things in
the backend that should be updated before various other signal
handlers, make sure so is done by emitting the signal after having
explicitly notified the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Call a CoglContext "cogl_context", CoglDisplay "cogl_display" and
CoglRenderer "cogl_renderer" so that they won't be confused with
ClutterContext, MetaDisplay and MetaRenderer etc.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make the cogl vfunc functions have names that are globally
discoverable. Calling the same function in every backend the same name
causes code navigation tools to not function properly. Rename the
affected functions to closer correspond to the style mutter uses.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
We were compensating for a clone paint viewport offset even when we
were not in clone paniting mode. This would break painting if we offset
the viewport for some other reason for example as in the future stage
view painting.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of assuming there is a single onscreen framebuffer, use the
helper functions for setting the frame callback and getting the frame
counter.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This commit completes the move of monitor logic to the monitor
mangager. The renderer now only deals with framebuffers, asking the
monitor manager to do the crtc flip tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
