Make the monitor implementation do things strictly related to its own
source type, leaving the Spa related logic and cursor read back in the
generic layer, later to be reused by the window source type
implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/413
Since commit 8df2a1452c (As pointed out by Robert Mader) we just happened
do this check when doing the first lookup for a Wayland surface for a
XWayland window, when we are later notifying upon surface creation we just
set the relation with no further checks.
The cases pointed out in the comment (eg. window changing decoration) might
presumably happen in a quick enough sequence that we have two scheduled
associations on the fly, so move this check to the more generic
meta_xwayland_associate_window_with_surface() which is called on both
immediate and delayed paths.
https://gitlab.gnome.org/GNOME/mutter/issues/361
There are most likely no GNOME users left still using hardware that
does not support NPOT textures. Further more, they would crash much
earlier and never hit this code-path. So remove the unnecessary check
here.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/447
XWayland creates buffers of the combined size of all connected displays.
This can, especially on older but still in use hardware, exceed the limits
of the GPU.
If that is the case, use `CoglTexture2DSliced` instead of `CoglTexture2D`
https://gitlab.gnome.org/GNOME/mutter/merge_requests/447
We might fail to page flip a new buffer, often after resuming, due to
the FIFO being full. Prior to this commit, we handled this by switching
over to plain mode setting instead of page flipping. This is bad because
we won't be synchronized to the refresh rate anymore, but just the
clock.
Instead, deal with this by trying again until the FIFO is no longer
full. Do this on a v-sync based interval, until it works.
This also changes the error handling code for drivers not supporting
page flipping to rely on them returning -EINVAL. The handling is moved
from pretending a page flip working to explicit mode setting in
meta-renderer-native.c.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/460
A renderer view will, under the native backend, since long ago always
have a logical monitor associated with it, so remove the code handling
the legacy non-stage view case.
https://gitlab.gnome.org/GNOME/mutter/issues/460
Prior to this commit, MetaWaylandSurface held a reference to
MetaWaylandBuffer, who owned the texture drawn by the surface. When
switching buffer, the texture change with it.
This is problematic when dealing with SHM buffer damage management, as
when having one texture per buffer, damaged regions uploaded to one,
will not follow along to the next one attached. It also wasted GPU
memory as there would be one texture per buffer, instead of one one
texture per surface.
Instead, move the texture ownership to MetaWaylandSurface, and have the
SHM buffer damage management update the surface texture. This ensures
damage is processed properly, and that we won't end up with stale
texture content when doing partial texture uploads. If the same SHM
buffer is attached to multiple surfaces, each surface will get their own
copy, and damage is tracked and uploaded separately.
Non-SHM types of buffers still has their own texture reference, as the
texture is just a representation of the GPU memory associated with the
buffer. When such a buffer is attached to a surface, instead the surface
just gets a reference to that texture, instead of a separately allocated
one.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
When we freed the cursor GPU state including the gbm_bo objects attached
to it, we didn't unset the cursor renderer private of the CRTCs of the
associated GPU. This means that HW cursor invalidation could potentially
break if a new gbm_bo happened to be allocated at the same memory
address as the previous one.
To avoid this, iterate through the CRTCs of the GPU of which the cursor
data is freed, and unset the cursor renderer private if it was the one
destroyed.
https://gitlab.gnome.org/GNOME/mutter/issues/199
What was actually done when calling meta_wayland_buffer_attach() was
that the texture was realized, so just call the function
`meta_wayland_dma_buf_realize_texture()` and call that.
This is in preparation to change how meta_wayland_buffer_attach() work.
https://gitlab.gnome.org/GNOME/mutter/issues/199
The signal handler must return TRUE as the invocation is already handled
by returning an error. Also update the error message a bit to clarify
that the API exists only for testing purposes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/457
We should not only take the old CRTC for an output whenever
possible, but we should also assign one that is 'free', i.e.
one that another monitor (to be processed after this one)
isn't using, so that that monitor can use the same CRTC.
https://gitlab.gnome.org/GNOME/mutter/issues/373
We shouldn't change an output's CRTC if we don't have to, as
that causes the output to go black.
This patch depends on
"monitor-unit-tests: initial crtcs in custom_lid_switch".
https://gitlab.gnome.org/GNOME/mutter/issues/373
This test forgot to specify the existing CRTC routings in the setup. For the
first output the default 0 was ok, now it is -1 to ensure that the code will
assign it correctly. For the second output the default 0 was incorrect, because
possible_crtcs does not include 0. Now that CRTC is initialized to off
instead, because the second output is hotplugged later and running a CRTC
without an output does not make sense.
This fix will keep this test passing when a future patch attempts to preserve
existing CRTC routings. Assuming that any existing routing is valid, such
routing will be kept. In this test case the existing routing was illegal, it
should have been impossible, which then causes that future patch to fail the
test by assigning the wrong CRTC.
https://gitlab.gnome.org/GNOME/mutter/issues/373
The external grab handler is shared across all external bindings and external
bindings have now different binding flags. For this reason, when rebuilding the
binding table there could be loss of information if we assign the bindings flags
of the external handler to all external bindings. Let's store the bindings flags
in MetaKeyGrab too and use this when rebuilding the binding table to avoid the
above issue.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/169
The "force restore shortcuts" being triggered by a key-combo, there is
no guarantee that the currently focused window is actually non-NULL in
which case we would crash.
Make sure there is a window currently focused before trying to restore
the shortcuts on that window.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/464
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
