Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
GTK+ won't be initialized if X11 is not available
Instead, when setting gtk-shell-shows-app-menu,
meta_prefs_set_show_fallback_app_menu should be
called as well.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Allow removing a prefs handler that was already removed. This allows us
to remove prefs from the dispose function without having to keep track
of it in every place.
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
These files are used to run mutter-test tools and using relative
paths won't work if the builddir doesn't match the srcdir.
This won't affect their installation (in case the build option is passed)
Make it so that each logical monitor has a reference to all the
monitors that are assigned to it.
All monitors has a reference to each output that belongs to it.
Each output has a reference to any CRTC it has been assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=786929
For some reason "backends: Remove X11 idle-monitor backend" removed
unrelated warning messages for when generated monitor configurations
that should work didn't, which also made the unit tests fail.
This commit adds them back, which also makes the tests pass again.
Commit 22723ca37 moved buffer realization to
meta_wayland_surface_commit() so that it wouldn't be part of
meta_wayland_buffer_attach().
However, creation of dmabuf buffers would call into
meta_wayland_buffer_attach() directly without realizing the buffer
first. attach() would then fail and mutter would effectively shut down
any clients using the zwp_linux_dmabuf protocol (note that if such
client was Xwayland, mutter itself would shut down as well).
Add the missing bit in order to make zwp_linux_dmabuf protocol work
again.
One of the current limitations of EGLStreams is that there's no way to
resize a surface consumer without re-creating the entire stream.
Therefore, while resizing, clients will send wl_surface::attach requests
so the compositor can re-create its endpoint of the stream, but no
buffer will be available actually. If we proceed with the rest of the
attach operation we'll be presenting an empty buffer.
In order to fix this, a separate wl_eglstream_controller protocol has
been introduced that clients can use to request a stream re-creation
without overloading wl_surface::attach for that purpose.
This change adds the required logic to create the corresponding
wl_eglstream_controller global interface that clients can bind to.
Whenever a client requests a stream to be created, we just need to
create and realize the new EGLStream buffer. The same buffer resource
will be given at a later time to wl_surface::attach, whenever new
content is made available by the application, so we can proceed to
acquire the stream buffer and update the surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Clients using EGLStream-backed buffers will expect the stream to be
functional after wl_surface::attach(). That means the compositor-side
stream must be created and a consumer attached to it.
To resolve the above, this change realizes buffers even when the attach
operation is deferred (e.g. synchronized subsurfaces).
https://bugzilla.gnome.org/show_bug.cgi?id=782575
When dealing with synchronized subsurfaces, we defer buffer attachments
until the parent surface state is applied.
That causes interaction issues with EGLStream backed buffers, as the
client expects the compositor-side stream to be functional after it
requests a wl_surface::attach.
By allowing the compositor to realize buffers without attaching them, we
could resolve the issue above if we define a realized EGLStream buffer
as a functional EGLStream (EGLStream + attached consumer).
This change moves the texture consumer creation part from the attach
function to the realize one.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Commit 712ec30cd9 added the logic to only
choose EGL configs that match the GBM_FORMAT_XRGB8888 pixel format.
However, there won't be any EGL config satisfying such criteria for
non-GBM backends, such as EGLDevice.
This change will let us choose the first EGL config for the EGLDevice
backend, while still forcing GBM_FORMAT_XRGB8888 configs for the GBM
one.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/2
Where to realize a hardware cursor depends on where on the screen it
will be displayed. For example it only needs buffers for the cursor
plane on a certain GPU if it overlaps with a monitor that is connected
said GPU.
Previously, we were too eager with uploading the cursor plane buffers,
which in effect resulted in the secondary GPU always being woken up
when changing the cursor, even though the cursor plane would actually
never be set unless the pointer cursor was moved to a monitor connected
to the secondary GPU. These wake-ups caused noticable stuttering; thus
by uploading the buffers more lazilly, the stuttering is avoided.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
When a cursor is hidden, the native backend will properly hide the HW
cursor sprite as well, but it would communicate this as if the cursor
was not handled by the backend, while in fact it still was. This caused
the generic cursor rendering layer to queue a redraw.
https://gitlab.gnome.org/GNOME/mutter/issues/77
When force-updating the HW state we might end up with a situation where
the HW cursor is no longer usable. If this would happen, we'd before
this commit not trigger the fallback paths using a GL texture.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It is already handled by the monitor-updated-internal signal handler in
meta-cursor-renderer-native.c, which will always be called indirectly
by resuming the monitor manager.
While at it, remove a useless comment.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Call it meta_cursor_renderer_update_cursor. This avoids confusing it
with the update_cursor MetaCursorRendererClass vfunc when navigating
the file.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It knows better when it's needed. For now, just do it just as before,
before drawing. Eventually, we can conditionalize where to realize
depending on the cursor sprite position.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Use a common entry point into the cursor renderer implementations HW
cursor realization paths for all cursor sprite types. This is in
preparation for realizing at more strategic times.
https://gitlab.gnome.org/GNOME/mutter/issues/77
The end goal here is to being able to realize at any point in time
through a single API, so start by moving state into the cursor sprite
implementation.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Remove some X11 compositing manager specific code from the general
purpose cursor tracker into a new MetaCursorSprite based special
purpose XFIXES cursor sprite.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Introduce a new type MetaCursorSpriteXcursor that is a MetaCursorSprite
implementation backed by Xcursor images. A plain MetaCursorSprite can
still be created "bare bone", but must be manually provided with a
texture. These usages will eventually be wrapped into new
MetaCursorSprite types while turning MetaCursorSprite into an abstract
type.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It was prefixed with meta_cursor_, but it took a X11 Display, so update
the naming. Eventually it should be duplicated depending if it's a
frontend X11 connection call or a backend X11 connection call and moved
to the corresponding layers, but let's just do this minor cleanup for
now.
https://gitlab.gnome.org/GNOME/mutter/issues/77
This makes it possible to move out backing store specific code (such as
Xcursor handling) to separate units, while also making it easier to add
more types).
https://gitlab.gnome.org/GNOME/mutter/issues/77
Rename the two cursor role types according to the convention used by the
other roles. This means that MetaWaylandSurfaceRoleCursor was renamed to
MetaWaylandCursorSurface, and MetaWaylandSurfaceRoleTabletCursor was
renamed to MetaWaylandTabletCursorSurface. The corresponding filenames
were renamed accordingly too.
https://gitlab.gnome.org/GNOME/mutter/issues/77
drmModeAddFB2 allows userspace to specify a real format enum on
non-ancient kernels, as an improvement over the legacy drmModeAddFB
which derives format from a fixed depth/bpp mapping.
As an optimisation, Weston used to decide at the first failure of
drmModeAddFB2 that the ioctl was unavailable: as non-existent DRM
ioctls return -EINVAL rather than -ENOSYS or similar, bad parameters are
not distinguishable from the ioctl not being present.
Mutter has also implemented the same optimisation for dumb framebuffers,
which potentially papers over errors for the gain of avoiding one ioctl
which will rapidly fail on ancient kernels. Remove the optimisation and
always use AddFB2 where possible.
Closes: #14
And ensure the actor is no longer reactive even though it might live longer
because of close effects, GCs, and whatnot. This ensures the actor is not
eligible for pointer picking within the destruction of its surface.
Closes: #188
The MetaCloseDialog implementation object may stay artifically alive
for a longer period. This was usually fine till gnome-shell commit
b03bcc85aad, as the check_alive() timeout will keep running even
though the window went unmanaged/destroyed, leading to crashes.
In order to fix this, forcibly hide the dialog if it is visible and
the window is being unmanaged, so the timeout is stopped in time.
The order of role creation is undetermined, so we can't account that
the parent surface will have a role (and an actor) at the time of
creating the wl_subsurface role for a child surface.
So we must do it both ways, add the subsurface as a child on
get_subsurface() if the parent already got a role, and lazily add
child subsurface actors to the current one if the parent surface got
it at a later point.
Related: #132
When using the EGLStream backend, the MetaRendererNative passed a
GClosure to KMS when using EGLStreams, but KMS flip callback event
handler in meta-gpu-kms.c expected a closure wrapped in a closure
container, meaning it'd instead crash when using EGLStreams. Make the
flip handler get what it expects also when using EGLStreams by wrapping
the flip closure in the container before handing it over to EGL.
https://bugzilla.gnome.org/show_bug.cgi?id=790316
Commit 47131b1d ("frames: Handle touch events") introduced an assert to
make sure that all mouse button actions are handled in mutter.
However, mice can have a more than 5 buttons, so simply ignore the
"other" actions instead of aborting.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/160
After 20176d03, the Wayland backend only synchronizes with the
compositor after a geometry was set, and it was different from
the current geometry.
That commit was mistakenly comparing the geometry before chaining
up, which would yield a false negative on the case where the
client didn't call set_geometry() before commit().
Fix that by caching the old geometry locally, chain up (and thus
apply the new geometry rectangle), then comparing the old and
current geometry rectangles.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/150
This avoids overwhelming the GPU with trying to update mipmaps at a high
rate. Because doing so could easily cause a reduction in the compositor
frame rate and thus actually reduce visual quality.
In the case of a window that is constantly animating in the overview,
this reduces mutter's render time by around 20%-30%.
This is just done on wayland as it'll break horribly on X11, we let
this happen through pointer emulated events in XISelectEvents evmask
instead.
Some things had to be made slightly more generic to accomodate touch
events. The MetaFrames shall lock onto a single touch at a time, we
don't allow crazy stuff like multi-window drag nor multi-edge resizes.
https://bugzilla.gnome.org/show_bug.cgi?id=770185
While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Various code assumed PipeWire function calls would never fail. Some can
actually fail for real reasons, and some currently can only fail due to
OOM situations, but we should still not assume that will always be the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/102
The destroyed signal that was emitted if an imported surface was not
available when created, for example if the handle was invalid or
already unexported, was emitted on the wrong resource.
To check if a subsurface is effectively synchronized, we walk the
subsurface hierarchy to look for a non-subsurface parent or a subsurface
being synchronized.
However, when client is closing, the parent surface might already be
gone, in which case we end up with a surface being NULL which causes a
NULL pointer dereference and a crash.
Check if the parent surface is NULL to avoid the crash, and consider
it's already synchronized if it is NULL to avoid further updates.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124
The current implementation of the XdgSurface v6 protocol does not check
if the window changed before calling meta_window_wayland_move_resize().
The problem with this approach is that calling this function is a costly
operation since we enter the compositor side. In GNOME Shell case, it is
in JavaScript, which triggers a GJS trampoline. Calling this function on
every mouse movement is naturally as terrible as it could be - and is
exactly what happens now.
This commit adds the necessary checks to only call move_resize() when
the window actually changed, or when it needs to be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
This will be used by the next commit to determine when a window
geometry change should be ignored or not. Normally, it would be
enough to just check if the position and sizes changed.
The position, in this case, is relative to the client buffer, not
the global position. But because it is not global, there is one,
admitedly unlikely, situation where the window state is updated
while the client size and relative positions don't change.
One can trigger this by e.g. tiling the window to the half-left of
the monitor, then immediately tile it to half-right. In this case,
the window didn't change, just it's state, but nonetheless we need
to notify the compositor and run the full move/resize routines.
When that case happens, though, the MetaWindowWayland is tracking
the pending state change or a move. And this is what we need to
expose.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
