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
Let MetaMonitorManagerKms manage KMS modes. This lets us pass less
state to MetaRendererNative. Instead let MetaMonitorManager tell the
monitor manager when it should set the mode and with what framebuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Absorb the CoglRendererKMS struct into MetaRendererNative. The gbm
device initialization is moved earlier so that the renderer fails to
initialize if the gbm device creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Use the correct pointer types for cogl objects. This avoids warnings
when including the cogl headers doesn't result in all the cogl types
being typedefs to void.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
All the upper layers are prepared for multiple onscreen cursors, but
this. All MetaCursorRenderers created would poke the same internal
MetaOverlay in the stage.
This will lead to multiple cursor renderers resorting to the "SW"
rendering paths (as it can be seen with tablet support) to reuse the
same overlay, thus leading to flickering when a different
MetaCursorRenderer takes over the overlay.
Fix this by allowing per-cursor-renderer overlays, their lifetime
is attached to the cursor renderer, so is expected to be tear down
if the relevant device (eg. tablet) disappears.
Sadly, GLib's autoptr cleanup macros cannot be detected by the C
pre-processor, because they generate a function. This means that we are
forced to bump up the dependency on GLib 2.49, in order to build against
a newer version of gdbus-codegen.
Starting from GLib 2.49, the gdbus-codegen tool automatically generates
the auto cleanup symbols for the GDBus proxy and skeleton interfaces.
Since we don't depend on a specific version of GLib we need to
conditionally generate the auto cleanup symbols in case an older version
of gdbus-codegen is used when building Mutter.
This commit unbreaks the build under GNOME Continuous, which has been
failing with:
usr/include/glib-2.0/glib/gmacros.h:415:43: error: redefinition of 'glib_autoptr_cleanup_Login1Session'
#define _GLIB_AUTOPTR_FUNC_NAME(TypeName) glib_autoptr_cleanup_##TypeName
^
[...]
/usr/include/glib-2.0/glib/gmacros.h:415:43: note: previous definition of 'glib_autoptr_cleanup_Login1Session' was here
./meta-dbus-login1.h:82:1: note: in expansion of macro 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
G_DEFINE_AUTOPTR_CLEANUP_FUNC (Login1Session, g_object_unref)
^
Wrap the existing laptop_display_is_on() method in a public function
that gnome-shell can use to query whether a builtin output is present
and enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=765267
While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible (i.e. any CoglError
that is not a malformed blend string).
https://bugzilla.gnome.org/show_bug.cgi?id=765058
The previous configuration might not apply because the number of
enabled outputs when trying to apply it might have changed. This isn't
a bug so we shouldn't assert. Instead, we can handle it by falling
back as we would if we didn't have a previous configuration to start
with.
https://bugzilla.gnome.org/show_bug.cgi?id=764286
On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.
Commit 4bebc5e5fa introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.
https://bugzilla.gnome.org/show_bug.cgi?id=763159
It indirectly triggers expensive operations in gnome-shell
(js/ui/keyboard.js), which turns out too expensive if we happen to operate
the shell simultaneously with 2 devices that will trigger the operations
there.
So just rate limit the signal emission, defer to an idle and just emit
the last device gotten. Worst that will happen is that we may possibly
emit the signal on the same device consecutively.
https://bugzilla.gnome.org/show_bug.cgi?id=753527
If we rely on getting back an input event with the warped pointer
coordinates, we might draw a frame with the old coordinates if we warp
during the paint phase. Avoid that by moving the cursor immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
In order to reuse some vector math for pointer confinement, move out
those parts to its own file, introducing the types old types
"MetaVector2" and "MetaLine2" outside of meta-barrier-native.c, as well
as introducing MetaBorder which is a line, with a blocking direction.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Add support for sending relative pointer motion deltas to clients who
request such events by creating wp_relative_pointer objects via
wp_relative_pointer_manager.
This currently implements the unstable version 1 from wayland-protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Instancing a gbm device without initializing EGL with it means that it
won't be able to import wl_drm buffers. Instead, let's re-use cogl's
gbm device which is already properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=761557
This fixes an issue analogous to bug 760330 for the X11 backend,
except on this backend we wouldn't crash accessing free'd memory.
Instead we're leaking watches since we steal them from the hash table
which means that when they're removed in
_meta_idle_monitor_watch_fire() they're no longer there and thus
they're never free'd.
https://bugzilla.gnome.org/show_bug.cgi?id=760476
Right now the XSync based idle monitoring code, will fetch all active
watches into a list, and then call their watch callbacks one by one
as necessary. If one watch callback invalidates another watch, the
list will contain free'd memory.
This commit makes sure to consult the hash table after ever call
of a watch callback, to ensure mutter never looks at freed memory.
Fixes crash reported on IRC by Laine Stump with his synergy setup.
https://bugzilla.gnome.org/show_bug.cgi?id=760330
We can know the rotation modes supported by the driver, so
export these as our supported modes, and ensure these modes
are honored on the CRTC primary plane upon apply_configuration().
It is worth noting however that not all hardware will be
capable of supporting all rotation modes (in fact, most of
them won't). A driver independent solution should be in
place to back up the rotation modes unsupported by the
drivers, so this is still a partial solution.
The cursor renderer has also been changed to default to
software-based rendering anytime the cursor enters a
rotated CRTC. Another solution would be actually rotating
the DRM cursor planes, but then it requires applying rotation on
these per-CRTC, and actually transforming the pointer position by
the output matrix. This brings marginal gains, so we use the
"sw" rendered cursor, which will be transformed together with
the primary plane.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
GDesktopTouchpadScrollMethod was used instead of GDesktopTouchpadClickMethod
which became visible now that the former has been removed from
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
When the touchpad is two-finger scrolling capable, always enable it.
When the touchpad only supports edge scrolling (usually older devices, and
usually smaller devices), allow disabling the edge scrolling.
This requires a newer gsettings-desktop-schemas as the scroll-method key
was removed, and the edge-scroll-enabled key added.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
The max potential number of logical monitors (i.e. MetaMonitorInfos)
is the number of CRTCs, not the number of outputs.
In cases where we have more enabled CRTCs than connected outputs we
would end up appending more MetaMonitorInfos to the GArray than the
size it was initialized with which means the array would get
re-allocated rendering invalid some MetaCRTC->logical_monitor pointers
assigned previously and thus ending in crashes later on.
https://bugzilla.gnome.org/show_bug.cgi?id=751638
On the wire, Wayland specifies the refresh rate in milliHz. Mutter sends
the refresh rate in Hz, which confuses clients, e.g. weston-info:
interface: 'wl_output', version: 2, name: 4
mode:
width: 2560 px, height: 1440 px, refresh: 0 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 5
mode:
width: 3200 px, height: 1800 px, refresh: 0 Hz,
flags: current preferred
and xrandr:
XWAYLAND0 connected 2560x1440+3200+0 600mm x 340mm
2560x1440@0.1Hz 0.05*+
XWAYLAND1 connected 3200x1800+0+0 290mm x 170mm
3200x1800@0.1Hz 0.03*+
Export the refresh rate in the correct units. For improved precision,
perform the KMS intermediate calculations in milliHz as well, and
account for interlaced/doublescan modes.
This is also consistent with what GTK+ expects:
timings->refresh_interval = 16667; /* default to 1/60th of a second */
/* We pick a random output out of the outputs that the window touches
* The rate here is in milli-hertz */
int refresh_rate = _gdk_wayland_screen_get_output_refresh_rate (wayland_display->screen,
impl->outputs->data);
if (refresh_rate != 0)
timings->refresh_interval = G_GINT64_CONSTANT(1000000000) / refresh_rate;
Where the 'refresh_rate' given is exactly what's come off the wire.
1000000000/60000 comes out as 16667, whereas divided by 60 is ...
substantially less.
https://bugzilla.gnome.org/show_bug.cgi?id=758653
