By the looks of it, commit 95e9fa10ef was taping over an Intel DRI bug
that would make it return post-swizzling pixel data on glReadPixels().
There's been reports over time of that commit resulting in wrong colors
on other drivers, and lately Mesa >17.3 started showing the same symptoms
on Intel.
But texture swizzling works by changing parameters before fragment shaders
and reading pixels from an already drawn FBO/texture doesn't involve those.
This should thus use pixel_format_to_gl_with_target(), which will result in
correctly requesting the same pixel format than the underlying texture,
while still considering it BGRA for the upper layers in the swizzling case.
https://gitlab.gnome.org/GNOME/mutter/issues/72Closes: #72
Mutter recently gained the ability to deal with multiple GPUs
rendering at different displays. These GPUs would have a display
connected to them, and Mutter was adapted in order to be aware
of different GPUs and their outputs.
However, one specific edge case appeared: PRIME systems. PRIME
systems have two GPUs:
* The integrated GPU (iGPU), usually Intel, which has connectors
and deals with the routine load.
* The dedicated GPU (dGPU), usually AMD or NVidia, which has no
connectors at all and are there just to aid heavy loads.
On those systems, the dGPU is aggressively put to sleep by the
kernel to avoid energy waste. Waking it up is a costly operation.
With Mutter's adaptation to deal with multiple GPUs, Mutter began
wakening the dGPU every time some rendering had to be done. This
was causing stuttering every time the dGPU was put to sleep, and
Mutter asked it to wake up again.
To fix this situation, this commit ignores GPUs with no connectors
attached.
Issue: #77
This is a small mistake spotted while working on a solution
for #77. When a GPU fails to initialize, we're adding them
anyway, which might have pretty bad consequences when trying
to use these NULL GPUs.
Issue: #77
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74Closes: #74
Actor keybindings were dispatched in an earlier return path, which means
the IM doesn't get to see certain key events. Flip the order around so the
IM has an opportunity to handle all keypresses.
https://gitlab.gnome.org/GNOME/mutter/issues/65Closes: #65
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63Closes: #63
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
Instead of bailing out when a seemingly random file is missing, require
the version of wayland-protocols that includes the source to create that
built file.
Introduced in d714a94
In order to let applications gracefully handle version mismatches, add
a version property to the APIs. Also add a warning on the APIs that
these are not meant for public consumption.
If the coordinates was for a stream not at the stage position (0, 0),
they'd be incorrect. Fix this by correctly translating the coordinates
according to the stream position.
