On X11, if a window cannot be maximized because its minimum size is
already larger than the output size, a request to maximize will be
ignored.
On Wayland, however, we would still honor the maximize request and
switch the window state to maximized, without actually moving the window
which leads to weird visual effects, as the window end up being
maximized in-place.
To avoid this, make sure the window has the maximize functionality
available prior to change its state in xdg-shell `set_maximized`
request.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/463
As per commit 43633d6b, we mark an unmanaging window as not focusable, while
this is true, it might cause not resetting the current focused window when
unmanaging it causing a crash.
Also this wouldn't allow to check if a window can be focused when unmanaging it,
so let's revert the previous behavior.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/462
This was wrongly done just before enable, which is not right as
per the protocol. A side effect was that input purpose/hints were
eagerly reset before being applied, thus not properly honored,
noticed in the doing of emoji/numeric OSK panels.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/410
This means we need to make sure we don't accidentally free the provided
source GError (which automatically happens with `g_autoptr`), so use
`g_steal_pointer()`.
This fixes an issue where, when launched in a bubblewrap environment
(such as the one provided by Buildstream), mutter would give the
following warning message:
```
mutter-WARNING **: 8:31:35:069: Can't initialize KMS backend: (null)
```
... which isn't that useful when trying to debug the actual issue.
Iterate over all the monitor product words to check for a partial matching on
EDID, otherwise we would hang inside an infinite while loop.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/459
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
This implements the viewporter protocol which offers a cropping and scaling
capabilities to wayland clients.
There are several use cases for this, for example video players and games,
both as a convenience function and as potential performance optimization when
paired with hardware overlays etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
For various error and warning messages, mutter includes a description of
the window, and that description includes a snippet of the title of the
window. Those snippets find their way into system logs, which then means
they can potentially find their way into bug reports and similar. Remove
the window title information to eliminate this potential privacy issue.
The helper function from gdbus-codegen broadcasts the signal emission,
but we really only care about sending it to the specific peer that
created the session. Thus, only emit the signal to the particular peer
that owns the session.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
If the extension is missing, the GPU copy path would not work. The code sets
the error, but forgets to return a failure. Fix this.
While adding the necessary return FALSE, also destroy the EGL context we just
created. Code refactoring shares the destroying code.
Found by reading code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/416
If the GPU copy path would use a software renderer, fall back to the CPU
copy path. The CPU copy path is possibly faster and avoids screen
corruption issues that were observed on an Intel Haswell desktop. The
corruption was likely due to texturing from an unfinished rendering or
memory caching issues.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/325
Print the pixel format chosen for an output on a secondary GPU for
debugging. Knowing the format can aid in debugging e.g. red/blue channel
swaps and CPU copy performance issues.
This adds a DRM format printing helper in meta-crtc-kms.h. This header
is included in most native backend files making it widely available,
while DRM formats are specific to the native backend. It could be shared
with Wayland bits, DRM format codes are used there too.
The helper makes the pixel format much more readable than a "%x".
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
When setting up an output on a secondary GPU with the CPU copy mode,
allocate the dumb buffers with a DRM format that is advertised supported
instead of hardcoding a format.
Particularly, DisplayLink devices do not quite yet support the hardcoded
DRM_FORMAT_XBGR8888. The proprietary driver stack actually ignores the
format assuming it is DRM_FORMAT_XRGB8888 which results the display
having red and blue channels swapped. This patch fixes the color swap
right now, while taking advantage if the driver adds support for XBGR
later.
The preferred_formats ordering is somewhat arbitrary. Here it is written
from glReadPixels point of view, based on my benchmarks on Intel Haswell
Desktop machine. This ordering prefers the format that was hardcoded
before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
These functions allow inspecting which pixel formats a CRTC's primary
plane supports. Future patches will inspect the supported formats and
pick a framebuffer format accordingly instead of hardcoding a format.
The copy list function will be used to initialize a formats list, and
the supports format function will be used to intersect that list against
another CRTC's supported formats.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
This avoids having to hardcode the same fallbacks elsewhere multiple
times when determining what formats might be suitable for a set of
CRTCs. The formats_modifiers hash table is now guaranteed to be
populated with at least something, so future code will not need to
handle it being empty.
The hardcoded fallback formats are a minimal set probably supported by
most hardware. XRGB8888 is the format that, according to ancient lore,
all DRM devices should support, especially if they don't have the
capability to advertise otherwise. Mutter also hardcodes XRGB8888 as the
GBM surface format, so it is already required on primary GPUs.
XBGR8888 matches the most common OpenGL format, sans alpha channel since
scanout hardware has not traditionally supported alpha. XBGR8888 is here
also because Mutter hardcodes that format for secondary GPU outputs when
using the CPU copy path.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
If the IN_FORMATS property is not found, copy the formats from the DRM
plane instead. This is the fallback for getting a list of formats the
primary plane supports when DRM universal planes capability is enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
Rather than picking just one format, parse and store all the formats and
their modifiers.
This gives us a list of supported formats (and modifiers) on a CRTC
primary plane. Later I will be using this list to choose a framebuffer
format instead of hardcoding it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/341
This is done through gtk-shell ATM. If a window requests focus with
an invalid startup ID, just the demands-attention flag will be set.
The "did user interaction happen in between" checks are left to
meta_window_activate_full/meta_window_focus, by passing the timestamp
of the original launch request.
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
It scaled the logical monitor rect with scale to get the stream
dimensions, but that is only valid when having
'scale-monitor-framebuffers' enabled. Even when it was, it didn't work
properly, as clutter_stage_capture_into() doesn't work properly with
scaled monitor framebuffers yet.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/415
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
Shell is using these, which was revealed by
1bbb5c8107 breaking its build when
generating its introspection due to meta_startup_notification_get_type()
not being found.
We keep the class structs private, so in practice MetaStartupSequence
and MetaBackend can't be derived from (the are semi-private).
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was
causing introspection to see this like a GDBus skeleton object exposing to
clients methods that were not required.
Also, this required us to export meta_dbus_* symbols to the library, while
these should be actually private.
So, make MetaMonitorManager to be just a simple GObject holding a skeleton
instance, and connect to its signals reusing most of the code with just few
minor changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
pkg-config files for mutter are generated using *_pkg_deps as requires, but
programs linked with libmutter doesn't need most of these private dependencies
which are only needed for building and linking mutter and its subprojects.
So list packages needed only by mutter itself inside *_pkg_private_deps and
don't expose such packages to pkg-config, but only use them at build time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Soname of the libraries should be the major version number, while the version
triplet is currently used:
objdump -p libmutter-4.so.0.0.0 | grep SONAME
SONAME libmutter-4.so.0.0.0
While is expected to be only libmutter-4.so.0
Fix all shared libraries by setting valid version and soversion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Some types were declared in the public headers so that g-ir-scanner
could resolve the types. This caused warnings when using
-Wredundant-decls, so only redeclare them for the gir scanner.
As with the commits earlier, this also adds const qualifiers where
expected. However, the const variables are casted to non-const variants
so they can be passed to glib functions that take non-const variants but
expect const-like input.
Previously, the clipping rectangle passed to
`meta_surface_actor_get_image()` was updated with the actual texture
size, but recent changes in `meta_shaped_texture_get_image()` now keep
the caller's clipping rectangle unchanged.
The implementation of `meta_window_actor_capture_into()` was relying on
the old behavior of updating the passed clipping rectangle, but now that
it's kept unchanged, the actual clipping rectangle used to copy the data
is wrong, which causes either a distorded image or worse, a crash of
mutter.
Use the resulting cairo image size to copy the data instead of the
clipping rectangle to avoid the issue and get the expected size.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/442
This is a GAppLaunchContext subclass meant to replace usage of
GdkAppLaunchContext in gnome-shell.
Launch contexts get created from the MetaStartupNotification as
they are closely related. The messaging underneath depends on
the availability of a X11 display, if there is one we go through
it (and libsn). If there is none, we still create startup sequences
manually for wayland clients.
A NULL argument is expected here in order to unset the selection,
meta_wayland_data_device_set_primary() accepts a NULL source, but
gtk_primary_selection_device.set_selection was not handling a
NULL wl_resource.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/335
The 'cursor-mode', which currently is limited to RecordMonitor(), allows
the user to either do screen casts where the cursor is hidden, embedded
in the framebuffer, or sent as PipeWire stream metadata.
The latter allows the user to get cursor updates sent, including the
cursor sprite, without requiring a stage paint each frame. Currently
this is done by using the cursor sprite texture, and either reading
directly from, or drawing to an offscreen framebuffer which is read from
instead, in case the texture is scaled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
There may be reasons to temporarly inhibit the HW cursor under certain
circumstances. Allow adding such inhibitations by adding API to the
cursor renderer to allow API users to add generic inhibitors with
whatever logic is deemed necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
To get a consistent behaviour no matter whether HW cursors are in use or
not, make sure to copy the framebuffer content before the stage overlays
(cursor sprite textures) are painted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
The "current" rect includes the frame, so in order to keep the
titlebar on screen, window movement must be restricted to at
most (height - titlebar_height) past the work area bottom.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/391
Mutter prefers platform devices over anything else as the primary GPU.
This will not work too well, when a platform device does not actually
have a rendering GPU but is a display-only device. An example of this
are DisplayLink devices with the proprietary driver stack, which exposes
a DRM KMS platform device but without any rendering driver.
Mutter cannot rely on EGL init failing on such devices either, because
nowadays Mesa supports software renderers on GBM, so the initialization
may well succeed.
The hardware rendering capability is recognized by matching the GL
renderer string to the known Mesa software renderers. At this time,
there is no better alternative to detecting this.
The secondary GPU data is abused for the GL renderer, as the Cogl
context may not have been created yet. Also, the Cogl context would
only be created on the primary GPU, but at this point the primary GPU
has not been chosen yet. Hence, GPU copy path GL context is used as a
proxy and predictor of what the Cogl context might be if it was created.
Mind, that even the GL flavour are not the same between Cogl and
secondary contexts, so this is stretch but it should be just enough.
The logic to choose the primary GPU is changed to always prefer hardware
rendering devices while also maintaining the old order of preferring
platform over boot_vga devices.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Moves the primary GPU choosing to after all secondary gpu data has been
created.
This makes it possible for a future patch to start looking at secondary
gpu data in choose_primary_gpu () to determine if it is using a hardware
driver or a software renderer.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Initialize the secondary GPU data for all GPUs, even the primary one. By
not looking at the primary_gpu_kms member, a future patch is allowed to
postpone choosing the primary GPU.
A future patch will use the secondary GPU data to decide which GPU will
become the primary GPU.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
create_renderer_gpu_data_egl_device () relied on the primary GPU being
already chosen for the "EGLDevice currently only works with single GPU
systems" error message. A future patch will choose the primary GPU after
this, not before, so this check needs to be rewritten before the
initialization order is changed.
The new check is implemented exactly as the error message says: there
must be exactly one GPU, otherwise fail.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Make the choosing and identity of the primary GPU an internal detail to
the native renderer. MonitorManagerKms did not need it for anything.
The primary GPU logic remains unchanged.
This allows follow-up patches to change how the renderer chooses the
primary GPU. It will be easier for the renderer to use private
information for choosing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
This is a step towards moving the primary GPU logic into the native
renderer exclusively. In the future the renderer will have one more
criterion on choosing the primary GPU than MetaMonitorManagerKms should
know about: does a GPU offer hardware rendering.
The choosing of primary GPU is separated from the discovery of GPUs.
When GPUs are discovered and added to the list, the MetaGpuKmsFlag is
now populated correctly and used in choosing.
Choosing the primary GPU is done after all GPUs have been found and is
slightly different from before:
- Skipping devices that do not belong to our seat now works instead of
becoming the primary GPU.
- Fall back to any non-platform, non-boot_vga device if neither kind is
found.
The old preference of platform over boot_vga device is kept.
The hotplug path will continue creating a gpu_kms without flags, because
at that point the primary GPU has already been chosen and the flags are
irrelevant.
Co-authored by: Pekka Paalanen <pekka.paalanen@collabora.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
Add a flags field to MetaGpuKms. In following commits, the flags defined
here will be set and used for choosing the primary GPU.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
If a library is provided in the positional arguments, then meson
defaults to installing the .pc file in a 'pkgconfig' subdirectory
in the library's install location. We want the files in the regular
$libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so
specify the location explicitly in the parameters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
This is a simple libcanberra abstraction object, so we are able
to play file/theme sounds without poking into GTK+/X11. Play
requests are delegated to a separate thread, so we don't block
UI on cards that are slow to wake up from power saving.
Dependencies are added automatically, and we no longer get warnings
like:
clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4
was passed to the "libraries" keyword argument of a previous call to
generate() method instead of first positional argument. Adding
mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour
that will change in a future version of Meson. Please report the issue
if this warning cannot be avoided in your case.
The texture tower can return no texture e.g. if the calculated level is
negative. This was handled before, but regressed with
e1370ee209. This fixes a potential crash
observed occasionally when starting Firefox nightly using the Wayland
backend in overview mode.
If a KMS device has the DRM_CAP_DUMB_PREFER_SHADOW and a software based
GL driver is used, always use a shadow fb. This will speed up read backs
in the llvmpipe OpenGL implementation, making blend operations faster.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/106
Now that everything is settled, from the initialization
process to the subclasses to moving code to the compositor,
MetaWindowActor can be a proper abstract class that cannot
be instantiated.
Thus, make MetaWindowActor an abstract class.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
This vfunc was added as a was to work around the convoluted
initialization process. Now that we figured it out and moved
the MetaWindowActor-specific initialization to constructed(),
we can override that.
Remove post_init() and use GObject.constructed() entirely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor breaks layering isolation by accessing
and injecting itself into compositor->windows. This is
a bad practice, and effecticely makes returning the
new actor useless, since we doesn't even use the return
value.
Move window actor creation to under MetaCompositor and
stop violating (too badly) the resposabilities of each
component. This moves meta_window_actor_new() into
meta_compositor_add_window().
Also, move the remaining initialization code to the
GObject.constructed vfunc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Document the roles of MetaSurfaceActor and MetaWindowActor,
and when their subclasses are used.
(And this is actually the first real documentation under
src/compositor/README!)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to
clients - even pure Wayland clients.
Now that we have Wayland- and X11-specific implementations of
MetaWindowActor, we can delegate this to MetaWindowActorX11,
and allow pure Wayland apps to not even connect to
MetaSurfaceActor:repaint-scheduled.
Do that by moving all the X11-specific code to the X11-specific
MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass
that are necessary for the move, namely:
* pre_paint() and post_paint()
* post_init()
* frame_complete()
* set_surface_actor()
* queue_frame_drawn()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Those are stub specialized classes for MetaWindowActor. This will
help ensuring that we do not execute X11-specific code paths on
pure Wayland clients.
The relationship between the window actor and the surface is the
following:
* Wayland: MetaWindowActorWayland + MetaSurfaceActorWayland
* X11: MetaWindowActorX11 + MetaSurfaceActorX11
* Xwayland: MetaWindowActorX11 + MetaSurfaceActorWayland
It is not possible to have MetaWindowActorWayland backed by a
MetaSurfaceActorX11 surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
We will introduce specialized MetaWindowActors for X11
and Wayland in the future, so it needs to be derivable.
Make it a derivable class, and introduce a private field.
The MetaWindowActorClass definition is in the private
header in order to prevent external consumers of Mutter
to create MetaWindowActor implementations of their own.
That is, MetaWindowActor is only internally derivable.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
EGLStream textures are imported as GL_TEXTURE_EXTERNAL_OES and reading
pixels directly from them is not supported. To make it possible to get
pixels, create an offscreen framebuffer and paint the actor to it, then
read pixels from the framebuffer instead of the texture directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
When a texture is transformed in any way (e.g. Wayland buffer
transforms), we cannot just fetch the pixels from the texture directly
and be done with it, as that will result in getting the untransformed
pixels.
To properly get the pixels in their right form, first draw to an
offscreen framebuffer, using the same method as when painting on the
stage, then read from the framebuffer into a cairo image surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/408
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. Mutter was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
https://bugzilla.gnome.org/show_bug.cgi?id=781034
This makes the build less verbose, as all .gir generation except for
clutters didn't pass --quiet to g-ir-scanner, making it output long
linking commands. Do this by adding a common introspection_args
variable.
While at it, put -U_GNU_SOURCE in there too, as it was always passed
everywhere as without it the scanner would log warnings.
This is the last remaining feature necessary to achieve
parity with the Autotools build.
A few changes were made to the install locations of the
tests, in order to better acomodate them in Meson:
* Tests are now installed under a versioned folder (e.g.
/usr/share/installed-tests/mutter-4)
* The mutter-cogl.test file is now generated from an .in
file, instead of a series of $(echo)s from within Makefile.
Notice that those tests need very controlled environments
to run correctly. Mutter installed tests, for example, will
failed when running under a regular session due to D-Bus
failing to acquire the ScreenCast and/or RemoteScreen names.
The Wacom Xorg driver assigns a serial number of 1 for any pad that doesn't
have a serial. libinput assigns 0. Just treat 1 as 0 here, there are no pens
with a real serial 1 anyway.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/414
Implements the `MetaScreenCastWindow` interface for screen-cast
`RecordWindow` mode.
`meta_window_actor_capture_into()` implementation is still pretty crude
and doesn't take into account subsurfaces and O-R windows so menus,
popups and other tooltips won't show in the capture.
This is left as a future improvement for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
Typically, to stream the content of a window, we need a way to copy the
content of its window-actor into a buffer, transform relative input
coordinates to relative position within the window-actor and a mean to
get the window bounds within the buffer.
For this purpose, add a new GType interface `MetaScreenCastWindow` with
the methods needed for screen-cast window mode:
* meta_screen_cast_window_get_buffer_bounds()
* meta_screen_cast_window_get_frame_bounds()
* meta_screen_cast_window_transform_relative_position()
* meta_screen_cast_window_capture_into()
This interface is meant to be implemented by `MetaWindowActor` which has
access to all the necessary bits to implement them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
To be able to cast windows, which by definition can change in size
dynamically, we need a way to specify the video crop meta to adjust to
the window size whenever it changes.
Add VideoCrop support with a new optional hook `get_videocrop()` in the
`ScreenCastStreamSrcClass` which, if defined, can let the child specify
a rectangle for the video cropping area.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/306
Switch-configs are only to be used in certain circumstances (see
meta_monitor_manager_can_switch_config()) so when ensuring
configuration and attempting to create a linear configuration, use the
linear configuration constructor function directly without going via the
switch config method, otherwise we might incorrectly fall back to the
fallback configuration (only enable primary monitor).
This is a regression introduced by 6267732bec.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342
Which eliminates the 1px jitter that was visible when dragging windows,
and eliminates the flickering that was visible when pushing the cursor
against the right/bottom edges of the screen.
The shader used for computing a vignette currently has two
problems:
* The math is wrong such that the vignette isn't stretched
across the whole actor and so ends abruptly
* There is noticeable banding in its gradient
This commit corrects both problems by fixing the computing
and introducing noise dithering.
If a display device (touchscreen, tablet with libwacom integration flags)
does not receive a monitor through settings. Delegate on the
MetaInputMapper so it receives a mapping through heuristics.
This object takes care of mapping absolute devices to monitors,
to do so it uses 3 heuristics, in this order of preference:
- If a device is known to be builtin, it's assigned to the
builtin monitor.
- If input device and monitor match sizes (with an error margin
of 5%)
- If input device name and monitor vendor/product in EDID match
somehow (from "full", through "partial", to just "vendor")
The most favorable outputs are then assigned to each device, making
sure not to assign two devices of the same kind to the same output.
This object replaces (and is mostly 1:1 with) GsdDeviceMapper in
g-s-d. That object would perform these same heuristics, and let
mutter indirectly know through settings changes. This object allows
doing the same in-process.
Since now we don't set the swap throttled value based
on sync-to-vblank, we can effectively remove it from
Cogl. Throttling swap buffers in Cogl is as much a
historical artifact as sync-to-vblank. Furthermore,
it doesn't make sense to disable it on a compositor,
which is the case with the embedded Cogl.
In addition to that, the winsys vfunc for updating
whenever swap throttling changes could also be removed,
since swap throttling is always enabled now.
Removing it means less code, less branches when running,
and one less config option to deal with.
This also removes the micro-perf test, since it doesn't
make sense for the case where Cogl is embedded into the
compositor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
Externally setting the sync-to-vblank setting was a feature
added as a workaround to old Intel and ATI graphic cards, and
is not needed anymore. Furthermore, it doesn't make sense to
change it on a compositor whatsoever.
This commit removes all the ways to externally change this
setting, as well as the now unused API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
The nested stage tries to emulate how CRTCs are drawn, but fails to do
this when a stage view is scaled as it didn't adapt the viewport size
according to the stage view scale.
https://bugzilla.gnome.org/show_bug.cgi?id=786663
Add MUTTER_DEBUG_DUMMY_MONITORS_SPECS env variable support so that you can define
a ':' separated list of monitor specs in the form of WWWxHHH@RR that will be
available for configuring the nested mutter.
When calculating the logical monitor layout size given a scale, don't
risk precision loss by float to int casting, which could result in a too
small layout.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Placing persistant Wayland popups (e.g. not menus etc) in the o-r layer
breaks stacking order with other window trees (e.g. other client
windows), as the menu would get stuck in the o-r layer, i.e. on top,
even if the parent of the popup got lowered.
Fix this by placing the popups in the normal layer, relying on
transient-ness to keep stacking correct.
When destructing a xdg_toplevel, we'll disassociate the actor from the
MetaWaylandSurface, to allow it to animate out. After having done this,
avoid trying to set it as unreactive when unsetting the window.
This fixes the runtime warning:
clutter_actor_set_reactive: assertion 'CLUTTER_IS_ACTOR (actor)' failed
Before processing the buffer damage region, intersect it with the buffer
rectangle to avoid trying to damage content outside the surface.
This fixes the runtime warning "GL error (1281): Invalid value"
happening when a client posts too large buffer damage larger.
We haven't supported disabling stage views in the native backend since
commit 70edc7dda4
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Mon Jul 24 12:31:32 2017 +0800
backends/native: Stop supporting stage views being disabled
There were still some left over checks; lets remove them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/343
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
The central part here is to recalculate the surface size accordingly
and to translate surface damage into buffer damage.
The choosen approach additionally lays groundwork for wp_viewporter
support, which is closely related in its nature.
A further explanation of buffer transforms from the specification:
> The purpose of this request is to allow clients to render content
> according to the output transform, thus permitting the compositor
> to use certain optimizations even if the display is rotated.
> Using hardware overlays and scanning out a client buffer for
> fullscreen surfaces are examples of such optimizations.
This adds the necessary bits to support Wayland buffer transforms.
The main part here is to properly setup the Cogl pipeline
and to recalculate the size of the painted area accordingly,
so culling etc. still works.
The choosen approach additionally lays groundwork for Wayland
wp_viewporter support.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/322
Commit 70036429bd mixed drag_origin and drag_surface, leading to warnings
and invisible drag icon. Fix this up so we correctly set up the feedback
actor. This will correctly display the DnD icon alongside the pointer.
It is meant to hold surfaces that require a ClutterActor, just like wl/xdg
shell surfaces and subsurfaces. Make it inherit from MetaWaylandActorSurface
so it gets that for free.
The type declaration is also made completely private, in order to avoid
cyclic dependency between meta-wayland-surface.h and
meta-wayland-actor-surface.h. We just require the GType fro assign_role()
anyway.
Modal ungrabs may be followed by other clients trying to grab themselves,
flush the connection so we ensure the right order of events on the Xserver
side.
An example of this is js/ui/modalDialog.js in gnome-shell, as the alt-F2
dialog may launch X11 clients trying to grab themselves, commit a40daa3c22
in gnome-shell handled the case and added a gdk_display_sync() call to
ensure no grab existed at the time of executing.
This commit aims to achieve the same built in MetaBackend. A full sync
seems excessive though, as we just need to make sure the server got the
messages queued before the other side tries to grab, a XFlush seems
sufficient for this.
The nested backend used the value from udev, meaning that one couldn't
configure the fake monitor if the laptop panel of the host was closed.
Avoid this annoyance by always having the nested backend claiming the
lid is open.
If meson tries to get ahead and generate object files for tests
at the same time than building libmutter, those may randomly fail
if meson did not create the libmutter generated headers yet.
Add those to the declared dependency, so the files are ensured to
be created before anything gets to use it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/404
It wasn't implemented by any subclass, it's not provided by DRM either.
And even if a subclass were to have only a file available, it could read
it into a GBytes as well and just use `read_edid()`.
Found this while working on !269.
It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
It cuts out some of the GObject boilerplate, and gives us g_autoptr()
support for free.
Since this changes the ABI, we also need to bump the libmutter API
version.
Because it is implemented and always on. By advertising this fact
the master clock is able to sync to the native refresh rate instead
of always using the fallback of 60.00Hz.
https://bugzilla.gnome.org/show_bug.cgi?id=781296
Add support for getting hardware presentation times from KMS (Wayland
sessions). Also implement cogl_get_clock_time which is required to compare
and judge the age of presentation timestamps.
For single monitor systems this is straightforward. For multi-monitor
systems though we have to choose a display to sync to. The compositor
already partially solves this for us in the case of only one display
updating because it will only use the subset of monitors that are
changing. In the case of multiple monitors consuming the same frame
concurrently however, we choose the fastest one (in use at the time).
Note however that we also need !73 to land in order to fully realize
multiple monitors running at full speed.
Use cogl_framebuffer_read_pixels_into_bitmap () instead of
glReadPixels () for the CPU copy path in multi-GPU support.
The cogl function employs several tricks to make the read-pixels as fast
as possible and does the y-flip as necessary. This should make the copy
more performant over all kinds of hardware.
This is expected to be used on virtual outputs (e.g. DisplayLink USB
docks and monitors) foremost, where the dumb buffer memory is just
regular system memory. If the dumb buffer memory is somehow slow, like
residing in discrete VRAM or having an unexpected caching mode, it may
be possible for the cogl function perform worse because it might do the
y-flip in-place in the dumb buffer. Hopefully that does not happen in
any practical scenario.
Calling meta_renderer_native_gles3_read_pixels () here was conceptually
wrong to begin with because it was done with the Cogl GL context of the
primary GPU, not on the GL ES 3 context of a secondary GPU. However,
due eglBindAPI being a no-op in Mesa and the glReadPixels () arguments
being compatible, it worked.
This patch adds a pixel format conversion table between DRM and Cogl
formats. It contains more formats than absolutely necessary and the
texture components field which is currently unused for completeness. See
Mutter issue #323. Making the table more complete documents better how
the pixel formats actually map so that posterity should be less likely
to be confused. This table could be shared with
shm_buffer_get_cogl_pixel_format () as well, but not with
meta_wayland_dma_buf_buffer_attach ().
On HP ProBook 4520s laptop (Mesa DRI Intel(R) Ironlake Mobile, Mesa
18.0.5), without this patch copy_shared_framebuffer_cpu () for a
DisplayLink output takes 5 seconds with a 1080p frame. Obviously that
makes Mutter and gnome-shell completely unusable. With this patch, that
function takes 13-18 ms which makes it usable if not fluent.
On Intel i7-4790 (Mesa DRI Intel(R) Haswell Desktop) machine, this patch
makes no significant difference (the copy takes 4-5 ms).
The format will be needed in a following commit in the CPU copy path
which stops hardcoding another format and starts using the format the
dumb FB was created with.
Change the callers of init_dumb_fb () to use DRM format codes. DRM and
GBM format codes are identical, but since this is about dumb buffers,
DRM formats fit better.
The header /usr/include/gbm.h installed by Mesa says:
* The FourCC format codes are taken from the drm_fourcc.h definition, and
* re-namespaced. New GBM formats must not be added, unless they are
* identical ports from drm_fourcc.
That refers to the GBM_FORMAT_* codes.
Virtual keyboard and pointer are freed on session close, but the
virtual touchscreen isn't.
Avoid a leak by freeing the virtual touchscreen along with the rest of
virtual devices.
We were using the connector_id for the winsys_id, but different
devices could have connectors with the same id. Since we use
winsys_id to uniquely identify outputs, use both the connector
id and the device id to avoid having outputs with the same id.
Following up last commit, this commit adds a CoglFramebuffer
argument to meta_shadow_paint(), and stops using the draw
framebuffer internally.
The only consumer of this API, MetaWindowActor, still passes
the draw framebuffer though.
MetaShadow.paint() uses Cogl implicit APIs (cogl_rectangle* ones, in
this case) to paint shadows with the shadow pipeline.
Replace those calls by cogl_framebuffer_draw_textured_rectangle()
calls, that achieve the exact same result but with the non-deprecated
API.
Python is not guaranteed to be installed in /usr/bin. This is especially
true for *BSD systems which don't consider Python as an integral part of
their systems.
We already ran a Wayland client to test various Wayland paths. What was
missing to also run a X11 client was to hook in the X11 async waiter
wires, so do that and run both types of clients.
https://bugzilla.gnome.org/show_bug.cgi?id=790207
As with the Wayland display name, to avoid clashes with already an
running Xwayland or Xorg instance, override the X11 display name to
something less likely to cause a clash.
https://gitlab.gnome.org/GNOME/mutter/issues/193
For Wayland outputs, we do not expose the actual transformation because
mutter does not support wl_surface.set_buffer_transform yet, instead we
swap the logical width and height when the output is rotated.
However, a client wishing to use the physical size would get confused,
so if the output is rotated, rotate the physical dimensions as well for
consistency.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/369
Moving windows using `move-to-side-X` and `move-corner-XX` keybindings
should keep windows within the confines of current screen.
`move-to-monitor-XXX` keybindings can be used to move windows to other
monitors.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/320
Commit 8d3e05305 ("window: Force update monitor on hot plugs") added the
flag `META_WINDOW_UPDATE_MONITOR_FLAGS_FORCE` passed to
`update_monitor()` from `update_for_monitors_changed()`.
However, `update_for_monitors_changed()` may choose to call another code
path to `move_between_rects()` and `meta_window_move_resize_internal()`
eventually.
As `meta_window_move_resize_internal()` does not use the "force" flag,
we may still end up in case where the window->monitor is left unchanged.
To avoid that problem, add a new `MetaMoveResizeFlags` that
`update_for_monitors_changed()` can use to force the monitor update from
`meta_window_move_resize_internal()`.
Fixes: 8d3e05305 ("window: Force update monitor on hot plugs")
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
Don't schedule redraws when being headless; there is nothing to draw so
don't attempt to draw. This also makes a flaky test become non-flaky, as
it previously spuriously got warnings due to windows being "painted"
when headless but lacking frame timings, as nothing was actually
painted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/170
The empty MetaStage was in meta-stage-private.h for no reason, so lets
move it to the C file. This makes it pointless to have a private
instance struct, so just move the fields to the private struct
_MetaStage.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/170
Instead of using gtk_css_provider_get_default(), add a
static GtkCssProvider and fetch it instead. Creating
GtkCssProviders consume a bit more memory, so keeping
a single one alive is slightly more memory saving.
It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
An unnecessary memory optimization, storing the tile mode as a 2 bit
unsigned integer, was used. While saving a few bytes, it made debugging
harder. Remove the useless byte packing.
Meson uses the 'dependencies' field to determine and
parallelize build steps, but that isn't entirely true
with 'link_with'; this might cause a race condition
when generating header files while trying to build
them.
Fix that by only using 'dependencies' instead of 'link_with'.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
The touch handling code uses evdev API, thus will not work on other
backends. Thus, put touch handling code behind runtime backend checks
and only include the code when native backend support is enabled.
Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
This is the filename convention you get when you define a shared module
in meson, and since there is no particular reason to not include the
"lib" prefix, lets make it easier to port it over. While at it,
de-duplicate the retrieval of the plugin name.
It'll be installed in the meta/ directory, so put the template files in
the corresponding directory in the tarball. This will also simplify the
port to meson.
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
testboxes was a binary that did unit testing, but it wasn't integrated
to the test system, so in effect, it was never run. Instead integrate it
into the other mutter unit tests. This includes changing a few of
meta_warning()s into g_warning()s so that the GTest framework can handle
them.
Closing a GdkDisplay during an event handler is not currently supported by Gdk
and it will result in a crash when doing e.g. 'mutter --replace'. Using an idle
function will close it safely in a subsequent main loop iteration.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/595
meta_workspace_manager_override_workspace_layout is implemented by
calling meta_workspace_manager_update_workspace_layout which
respects the workspace_layout_overridden flag. After the first call
to meta_workspace_manager_override_workspace_layout all subsequent
calls fail silently.
Reset workspace_layout_overridden to FALSE before calling
meta_workspace_manager_update_workspace_layout.
https://gitlab.gnome.org/GNOME/mutter/issues/270
drmModePageFlip() is guaranteed to fail for the invalid FB id 0.
Therefore it never makes sense to call this function with such argument.
Disabling a CRTC must be done with SetCrtc instead, for example.
Trying to flip to FB 0 not only fails, but it also causes Mutter to
never try page flip on this output again, using drmModeSetCrtc()
instead.
There was a race in setting next_fb_id when a secondary GPU was using
the CPU copy path. Losing this race caused the attempt to
drmModePageFlip () to FB ID 0 which is invalid and always fails. Failing
to flip causes Mutter to fall back to drmModeSetCrtc () permanently.
In meta_onscreen_native_swap_buffers_with_damage ():
- update_secondary_gpu_state_pre_swap_buffers ()
- copy_shared_framebuffer_cpu () but only on the CPU copy path
- secondary_gpu_state->gbm.next_fb_id is set
- wait_for_pending_flips ()
- Waits for any remaining page flip events and executes and destroys
the related page flip closures.
- on_crtc_flipped ()
- meta_onscreen_native_swap_drm_fb ()
- swap_secondary_drm_fb ()
- secondary_gpu_state->gbm.next_fb_id = 0;
- meta_onscreen_native_flip_crtcs ()
- meta_onscreen_native_flip_crtc ()
- meta_gpu_kms_flip_crtc () gets called with fb_id = 0
This race was observed lost when running 'mutter --wayland' on a machine
with two outputs on Intel and one output on DisplayLink USB dock, and
wiggling around a weston-terminal window between the Intel and
DisplayLink outputs. It took from a second to a minute to trigger. For
testing with DisplayLink outputs Mutter also needed a patch to take the
DisplayLink output into use, as it would have otherwise been ignored
being a platform device rather than a PCI device.
Fix this race by first waiting for pending flips and only then
proceeding with the swap operations. This should be safe, because the
pending flips could have completed already before entering
meta_onscreen_native_swap_buffers_with_damage ().
We might unset focus, or already be out of focus (e.g. an X11 client or
clutter text entry is focused) when a text-input state is committed by
the client. We handled this before, except when text input was
explicitly disabled by the client, the Wayland text-input was in focus
by the input method, and it focused itself out.
Simplify the logic a bit by just dropping the state on the floor in all
cases where after any potential focus changes were done, we are not
focused.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/353
Commit 840378ae68 changed the code to use XmbTextPropertyToTextList()
instead of gdk_text_property_to_utf8_list_for_display(), but didn't
take into account that the replacement returns text in the current
locale's encoding, while any callers (rightfully) expect UTF8.
Fix this by converting the text if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
The WM_NAME property is of type TEXT_PROPERTY, which is supposed to be
returned as UTF-8. Commit 840378ae68 broke that assumption, resulting
in crashes with non-UTF8 locales; however the "fix" of converting from
LATIN1 to UTF8 is wrong as well, as the conversion will spit out garbage
when the input encoding isn't actually LATIN1.
Now that the original issue in text_property_to_utf8() has been fixed,
we can simply revert the relevant bits of commit d62491f46e.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
In order to allow a window with a custom rule placement to be moved
together with its parent, the final rule used derived from the
constraining were used for subsequent constraints. This was not enough
as some constraining cannot be translated into a rule, such as sliding
across some axis.
Instead, make it a bit simpler and just remember the position relative
to the parent window, and use that the next time.
This is a rework of 5376c31a33 which
caused the unwanted side effects.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/332
When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).
Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.
When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.
The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
When repicking after a surface was destroyed, if the destroyed surface
was the drag focus, we'd try to focus-out from it after it was
destroyed, causing a NULL pointer dereference.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336
With Wayland, a window is not showing until it's shown. Until this
patch, the initial state of MetaWindow, on the other hand, was that a
window is initialized as showing. This means that for a window to
actually be classified as shown (MetaWindow::hidden set to FALSE),
something would first have to hide it.
Normally, this wasn't an issue, as normally we'd first create a window,
determine it shouldn't be visible (due to missing buffer), hide it
before the next paint, then eventually show it. This doesn't work if
mutter isn't drawing any frames at the moment (e.g. the user switched
VT), as we'd miss the hiding before showing as e result of a buffer
being attached. The most visible side effect is that a window can't be
moved as the window actor remains frozen.
This commit fixes this issue by correctly classifying a newly created
Wayland window as "hidden".
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/331
The clip and opaque region are both in a translated stage coordinate
space, where the origin is in the top left corner of the painted
texture. The painting, however, is in the texture coordinate space,
so when the texture is scaled, the coordinate spaces differ.
Handle this by transforming the clip and opaque region to texture
coordinate space before computing the blend region and the opaque region
to paint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/300
They were int before entering MetaShapedTexture, used as ints in the
cairo regions and rectangles, so there is no reason they should be
stored as unsigned.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/300
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
Track the allocated dumb buffer size in MetaDumbBuffer. Assert that the
size is as expected in copy_shared_framebuffer_cpu().
This is just to ensure that Cogl and the real size match. The size from
Cogl was used in the copy, so getting that wrong might have written
beyond the allocation.
This is a safety measure and has not been observed to happen yet.
If drmModeAddFB2() does not work, the fallback to drmModeAddFB() can
only handle a single specific format. Make sure the requested format is
that one format, and fail the operation otherwise.
This should at least makes the failure mode obvious on such old systems
where the kernel does not support AddFB2, rather than producing wrong
colors.
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.
In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.
Closes: #273
The compositor will automatically unredirect the top most window which
is fully visible on screen. When unredirecting windows, it also shapes
the compositor overlay window (COW) so that other redirected windows
still shows correctly.
The function `get_top_visible_window_actor()` however will simply walks
down the window list, so if a window is placed on a layer above and
unredirected, then iconified by the client, it will still be picked up
by `get_top_visible_window_actor()` and he compositor will reckon it's
still unredirected while not in a visible state anymore, thus leaving a
black area on screen.
Make sure we skip the windows not known to the compositor while picking
the top visible window actor to avoid this issue.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/306
Previously, trackballs were detected based on the presence of the
substring "trackball" in the device name. This had the downside of
missing devices, such as the Kensington Expert Mouse, which don't have
"trackball" in their names.
Rather than depending on the device name, use the ID_INPUT_TRACKBALL
property from udev to determine whether or not to treat a device as a
trackball.
This adds a new function, `is_trackball_device`, to MetaInputEvents, and
eliminates the `meta_input_device_is_trackball` function.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
On Wayland, xdg-foreign would leave a modal dialog managed even after
the imported surface is destroyed.
This is sub-optimal and this breaks the atomic relationship one would
expect between the parent and its modal dialog.
Make sure we unmanage the dialog if transient_for is unset even for
Wayland native windows.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Related: https://gitlab.gnome.org/GNOME/mutter/issues/221
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
A window placed using a placement rule should keep that relative
position even if the parent window moves, as the position tied to the
parent window, not to the stage. Thus, if the parent window moves, the
child window should move with it.
In the implementation in this commit, the constraints engine is not
used when repositioning the children; the window is simply positioned
according to the effective placement rule that was derived from the
initial constraining, as the a xdg_popup at the moment cannot move
(relative its parent) after being mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/274
As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
without the client knowing about it, meaning the client may still send
updates and make requests. Handle this gracefully by ignoring them. The
client needs to reset all the state anyway, if it wants to remap the
same surface.
https://gitlab.gnome.org/GNOME/mutter/issues/240
As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
the compositor without the client knowing about it, meaning the client
may still send updates and make requests. Handle this gracefully by
ignoring them. The client needs to reassign the surface the legacy
xdg-toplevel role again, if it wants to remap the same surface, meaning
all state would be reset anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped because the
surface was reassigned the toplevel role, the cached frame callbacks
will be queued on the surface actor and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A window can be unmanaged without asking the client to do it, for
example as a side effect of a parent window being unmanaged, if the
child window was a attached dialog.
This means that the client might still make requests post updates to it
after that it was unmapped. Handle this gracefully by NULL-checking the
surface's MetaWindow pointer. We're not loosing any state due to this,
as if the client wants to map the same surface again, it needs to either
reassign it the toplevel role, or reset the xdg-toplevel, both resulting
in all state being lost anyway.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped, either because
the surface was reassigned the toplevel role, or if it was reset and
remapped, the cached frame callbacks will be queued on the surface actor
and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A popup can be reset, and when that happens, window and actor are
destroyed, and won't be created again unless it is reassigned the
popup role.
If a client queued frame callbacks when resetting a popup, the frame
callbacks would be left in the pending state, as they were not queued on
the actor, meaning we'd hit an assert about the frame callbacks not
being handled. Fix this by caching them on the MetaWaylandSurface, so
that they either are cleaned up on destruction, or queued on the actor
would the surface be re-assigned the popup role.
https://gitlab.gnome.org/GNOME/mutter/issues/240
Sometimes it may be useful for roles to put callbacks in the generic
surface frame callback queue. The surface frame callback queue will
either eventually be processed on the next surface role assignment that
places the frame callbacks in a role specific queue, processed at some
other point in time by a role, or cleaned up on surface destruction.
https://gitlab.gnome.org/GNOME/mutter/issues/240
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.
Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.
https://gitlab.gnome.org/GNOME/mutter/issues/240
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.
The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.
As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
The "backends: Move MetaOutput::crtc field into private struct"
accidentally changed the view transform calculation code to assume that
"MetaCrtc::transform" corresponds to the transform of the CRTC; so is
not the case yet; one must calculate the transform from the logical
monitor, and check whether it is supported by the CRTC using
meta_monitor_manager_is_transform_handled(). This commit restores the
old behaviour that doesn't use MetaCrtc::transform when calculating the
view transform.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/216
XcursorLibraryLoadCursor can return 'None' if the current cursor theme
is missing the requested icon. If XFreeCursor is then called on this
cursor, it generates a BadCursor error causing gnome-shell to crash.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/254
We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
As per specification
> The compositor ignores the parts of the input region that
> fall outside of the surface.
> The compositor ignores the parts of the opaque region that
> fall outside of the surface
This fixes culling problems under certain conditions.
Currently xdg-shell applies a geometry set with set_window_geometry
unconditionally. But the specification requires:
> When applied, the effective window geometry will be
> the set window geometry clamped to the bounding rectangle of the
> combined geometry of the surface of the xdg_surface and the
> associated subsurfaces.
This is especially important to implement viewporter and
transformation.
By using the shm file when sending the keymap to all clients, we
effectively allows any client to change the keymap, as any client has
the ability to change the content of the file. Sending a read-only file
descriptor, or making the file itself read-only before unlinking, can
be worked around by the client by using chmod(2) and open(2) on
/proc/<pid>/<fd>.
Using memfd could potentially solve this issue, but as the usage of
mmap with MAP_SHARED is wide spread among clients, such a change can
not be introduced without causing wide spread compatibility issues.
So, to avoid allowing clients to interfere with each other, create a
separate shm file for each wl_keyboard resource when sending the
keymap. We could eventually do this per client, but in most cases,
there will only be one wl_keyboard resource per client anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=784206
If a client maps a popup in response to a key-down event, but the
mapping doesn't occur until after the user has already released the same
button, we'd immediately dismiss the popup. This is problematic, as one
often presses and releases a key quite quickly, meaning any popup mapped
on key-down are likely to be dismissed.
Avoid this race condition by accepting serials for key down events, if
the most recent key-up event had the same keycode.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/180
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
meta_backend_x11_grab_device is performing X server clock comparison
using the MAX macro, which comes down to a simple greater-than.
Use XSERVER_TIME_IS_BEFORE, which is a better macro for X server
clock comparisons, as it accounts for 32-bit wrap-around.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/174
Commit c0d9b08ef9 replaced the old GBM API calls
with the multi-plane GBM API. However, the call to gbm_bo_get_handle_for_plane
fails for some DRI drivers (in particular i915). Due to missing error checks,
the subsequent call to drmModeAddFB[2] fails and the screen output locks up.
This commit adds the missing error checks and falls back to the old GBM API
(non-planar) if necessary.
v5: test success of gbm_bo_get_handle_for_plane instead of errno
This commit adopts solution proposed by Daniel van Vugt to check the return
value of gbm_bo_get_handle_for_plane on plane 0 and fall back to old
non-planar method if the call fails. This removes the errno check (for
ENOSYS) that could abort if mesa ever sets a different value.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/127
If the surface is gone before `meta_xwayland_keyboard_grab_end()` is
called, we would bail out early leaving an empty grab, which will cause
a segfault as soon as a key is pressed later on.
Make sure we clean up the keyboard grab even if the surface is gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/255
The string used to point to memory owned by libwayland-server, but
with the ability to override the display name, we took over ownership
by copying the string as necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
Thanks to G_DEFINE_DYNAMIC_TYPE_EXTENDED(), this is a trivial addition that
will allow using G_IMPLEMENT_INTERFACE_DYNAMIC() or G_ADD_PRIVATE_DYNAMIC()
when declaring a plugin.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
For historical reasons meta_monitor_is_active() checked whether it is
active by checking whether the main output have a CRTC assigned and
whether that CRTC has a current mode. At a later point, the MetaMonitor
got its own mode abstraction (MetaMonitorMode), but
meta_monitor_is_active() was never updated to use this.
An issue with checking the main output's CRTC state is that, if there is
some CRTC mode combination that for some reason isn't properly detected
by the MetaMonitorMode abstraction (e.g. some tiling configuration not
yet handled), meta_monitor_is_active() would return TRUE, even though no
(abstracted) mode was set. This would cause confusion here and there,
leading to NULL pointer dereferences due to the assumption that if a
monitor is active, it has an active mode.
Instead, change meta_monitor_is_active() to directly check the current
monitor mode, and log a warning if the main output still happen to have
a CRTC with a mode assigned to it. This way, when an not undrestood CRTC
mode combination is encountered, instead of dereferencing NULL pointers,
simply assume the monitor is not active, which means that it will not be
managed or rendered by mutter at all.
https://gitlab.gnome.org/GNOME/mutter/issues/130
When a transient window is destroyed, the expected behavior is that
focus is passed to the ancestor if possible. This was broken for
quite a while until the previous commit, so add a test case to make
sure it doesn't happen again.
https://gitlab.gnome.org/GNOME/mutter/issues/15
Since commit b3b9d9e16 we no longer have to pass the unmanaging window
to make sure we don't try to focus it again, however the parameter also
influences the focus policy by giving ancestors preference over the normal
stack order.
https://gitlab.gnome.org/GNOME/mutter/issues/15
We refuse to move focus while a grab operation is in place. While this
generally makes sense, there's no reason why the window that owns the
grab shouldn't be given the regular input focus as well - we pretty
much assume that the grab window is also the focus window anyway.
In fact there's a strong reason for allowing the focus change here:
If the grab window isn't the focus window, it probably has a modal
transient that is focused instead, and a likely reason for the focus
request is that the transient is being unmanaged and we must move
the focus elsewhere.
https://gitlab.gnome.org/GNOME/mutter/issues/15
Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState
excessively-low screen resolutions setting both a minimum width and a minimum
height. GetCurrentState is e.g. used by Gnome Control Center to build a list of
selectable resolutions.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
If a client asks for xdg-output before we have set the output's logical
monitor, we would end up crashing with a NULL pointer dereference.
Make sure we clear the resource's user data when marking an output as
inert on monitor change so that we don't end up with a Wayland output
without a logical monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
Add API to let GNOME Shell have the ability to get notified about remote
access sessions (remote desktop, remote control and screen cast), and
with a way to close them.
This is done by adding an abstraction above the remote desktop and
screen cast session objects, to avoid exposing their objects to outside
of mutter. Doing that would result in external parts holding references
to the objects, complicating their lifetimes. By using separate wrapper
objects, we avoid this issue all together.
This test aims at checking that the transient relationship set using the
xdg-foreign API is respected by mutter and that no crash occurs, such as
the one in issue !174.
Note: the crash from issue !174 occurs only if "attach_modal_dialogs" is
set, so one has to change that default value to "true" to be able to
trigger the crash:
gsettings set org.gnome.mutter attach-modal-dialogs true
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Add a "set_parent_exported" command to test the xdg-foreign support, so
that we can add a test which uses the GDK API for exported window:
`gdk_wayland_window_set_transient_for_exported()`
That will allow to detect if transient is applied correctly between
foreign windows and detect possible crashes such as issue !174.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Monitor whether UPower is running ourselves. That allows us to keep the
same value for "lid-is-closed" throughout the process of UPower
restarting, preventing unwanted monitor re-configuration through the process.
Fixes another screen black out when UPower restarts and the laptop lid
is closed.
Rather than handle UpClient in both MetaBackend (to reset the idletime
when the lid is opened), and in MetaMonitorManager and
MetaMonitorConfigManager (to turn the screen under the lid on/off
depending on its status), move the ability to get the lid status from
UPower or mock it in one place, in MetaBackend.
Restarting UPower will make every property of UpClient emit a "notify"
signal (as a GDBusProxy would). Avoid mutter reconfiguring the displays
when upower restarts by caching the last known value of "lid-is-closed"
and only reconfiguring the displays if it actually changed.
This fixes a black out of the screen when UPower restarts.
Previously we relied on the test-client to make sure that a window was
shown. For X11, we did not need to do anything, but for Wayland we had
to make sure we had drawn the first frame, otherwise mutter wouldn't
have a buffer making the window not showable.
Doing it this way doesn't work anymore however, since the 'after-paint'
event will be emitted even if we didn't actually paint anything. This is
the case with current Gtk under Wayland, where we won't draw until the
compositor has configured the surface. In effect, this mean we'll get a
dummy after-paint emission before the first frame is actually painted.
Instead, move the verification that a "show" command has completed by
having the test-runner wait for a "shown" signal on the window, which is
emitted in the end of meta_window_show(). This requires an additional
call to gdk_display_sync() in the test-client after creating the window,
to make sure that the window creation vents has been received in the
compositor.
As of "stack-tracker: Keep override redirect windows on top"
(e3d5bc077d), we always sorted all
override redirect on top of regular windows, as so is expected by
regular override redirect windows. This had an unwanted consequence,
however, which is that we should still not sort such override redirect
windows on top if they are behind the guard window, as that'd result in
windows hidden behind it now getting restacked anyway.
Fix this by only sorting the override redirect windows that are found
above the guard window on top. This fixes the override-redirect stacking
test.
The special ::pick implementation there makes clutter fall into paths
that do require a get_paint_volume() implementation, or an infinite
area will be used.
Providing a paint volume here is easier on the invalidation mechanism.
This optimization was presumably added before Clutter was able to
invalidate selected regions of an actor. Paint volumes are supposed
to be invariable as long as the actor conditions don't change.
Stacking of other actors shouldn't affect the paint volume, so it's
actually wrong to optimize those areas away here.
