These were leftovers from times when GL(ES) 1.x was still supported.
As we require HAVE_COGL_GL and/or HAVE_COGL_GLES2 to be defined, all
cases for checking both are now redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3338>
These functions ends-up calling gdk-pixbuf for loading textures/bitmaps
from a file and they don't seem to be used anywhere.
These changes are only useful with the following up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3097>
Every `mtk_x11_error_trap_push()` must be paired
with an `mtk_x11_error_trap_pop[_with_return]()` call
otherwise all future errors will be caught and ignored
even if they shouldn't be.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3328>
They are needed as "subformats" for higher bit YCbCr formats, such as
P010, and we don't plan to use or expose them otherwise. Thus don't
implement any conversion or packing features.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
Or else `glXQueryDrawable` will fail per the `GLX_EXT_buffer_age` spec:
> If querying GLX_BACK_BUFFER_AGE_EXT and <draw> is not bound to
> the calling thread's current context a GLXBadDrawable error is
> generated.
This mistake went unnoticed until `mtk_x11_error_trap_push` was introduced
(55e3b2e519) because for some reason it is incapable of trapping
`glXQueryDrawable`. Prior to that it seems
`cogl_onscreen_glx_get_buffer_age` would trap and so always returned zero.
This means we're reenabling clipped redraws on X11 here for the first
time in a long time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3255>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
On GLES2 reading and writing some Cogl formats is not supported
natively. In those cases we use another format to do the reading and
writing. When the internal format and the temporary format differ in
premultiplication, Cogl tries to adjust for it.
Opaque Cogl formats don't have the premult bit set but our internal
format is a premult format. Cogl tries to adjust for it but completely
misses that the opaque format doesn't have an alpha channel and it
should not do so at all.
So skip the premult adjusting when the Cogl format has no alpha channel.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
As it is the only place where cogl depends directly on cairo minus
the whole cairo_region_t.
The motivation behind the removal of this helper is to reduce the usage
of cairo in libmutter is to potentially completely drop it in
certain places or replace it with pixman.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3079>
glGetIntegerv() with GL_RED_BITS/GL_GREEN_BITS/GL_BLUE_BITS/etc. is not
supported with the GL core context, so there is no point in falling back
to that without supporting COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS,
as this will cause an GL error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
The function ensure_bits_initialized() in cogl-gl-framebuffer-fbo.c
checks for COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS whereas the same
in cogl-gl-framebuffer-back.c simply checks for the driver being
COGL_DRIVER_GL3.
Change the later to use the COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS
flag as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
Cogl's feature COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS is required
to use the GL_FRAMEBUFFER_ATTACHMENT_* queries.
Unfortunately, the test for the availability of the private feature is
actually inverted in ensure_bits_initialized() which causes that whole
portion of code to be ignored, falling back to the glGetIntegerv()
method which isn't supported in core profiles.
As Mesa has recently started to be more strict about these, this causes
the CI tests to fail in mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
