CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In cogl use cogl-config.h and in clutter use clutter-build-config.h. We
can't use clutter-config.h in clutter because its already used and
installed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
If you include a file that might define __INSIDE_COGL_H__, don't
undefine it if it wasn't defined in that file. This makes it possible
to include for example cogl-gles2.h from some other file which defines
__INSIDE_COGL_H__.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
When using a context with robustness, glGetError() may return
GL_CONTEXT_LOST at any time and this error doesn't get cleared until
the application calls glGetGraphicsResetStatus() . This means that our
error checking can't call glGetError() in a loop without checking for
that return value and returning in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
commit 188752158 changed cogl to stop needlessly creating its own
monitor output configuration when mutter would just soon overwrite
it anyway.
Unfortunately, that commit is causing a crash in some cases because
cogl will now create and later draw to a 0x0 egl surface until mutter
sets the monitor layout.
This commit changes cogl to avoid creating and using a surface, before
it knows how big of a surface to create.
https://bugzilla.gnome.org/show_bug.cgi?id=758073
If we get EACCES from drmPageFlip we're not going to get
a flip event and shouldn't wait for one.
This commit changes the EACCES path to silently ignore the
failed flip request and just clean up the fb.
https://bugzilla.gnome.org/show_bug.cgi?id=756926
ES3 provides glMapBufferRange as core, with the added bonus that it also
supports read mappings. Use this where possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
GLES2 does not support passing READ to glMapBuffer; attempting to call
cogl_buffer_map for read on ES2 will bring it down with an assert. Make
sure COGL_DEBUG=journal doesn't do this when it's not possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
On Wayland deinit() of an onscreen buffer is going to destroy the
associated native window of an EGLSurface. So we should destroy the
EGLSurface as well otherwise we might end up confusing the GL driver.
We also currently guard against setting a EGL_NO_SURFACE as current
EGLSurface, but this shouldn't be a problem if we have a surfaceless
context. So we allow surface destruction under that condition.
https://bugzilla.gnome.org/show_bug.cgi?id=754667
If the user switches VTs in the middle of a page flip, the
page flip operation may fail with EACCES. page flipping will
work next time the VT becomes active, so we shouldn't disable
page flipping in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
If cogl fails to open the drm device, initialize gbm, or open the
egl display, then it closes the drm fd, uninitializes gbm, closes the
display and then calls _cogl_winsys_renderer_disconnect which does
most of those things again, on the, now deinitialized, members.
This commit removes the explicit failure handling in renderer_connect and
defers cleanup to disconnect.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
gbm confusingly has two different format types, and cogl
is using the wrong one in some of its calls to gbm_surface_create
This commit fixes the calls that are wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
glGetIntegerv (GL_DEPTH_BITS, ...) and friends are deprecated in GL3; we
have to use glGetFramebufferAttachmentParameteriv() instead, like we do
for offscreen framebuffers.
Based on a patch by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=753295
We want to be able to retrieve the XVisualInfo used when creating the
GL context under GLX and EGL-X11, so that we can use the visual before
we have an onscreen frame buffer.
Initialize variables; GCC does not always catch all cases where the
variables are used after being initialized, especially when it comes to
out parameters.
Some drivers ( like mgag200 ) don't yet support drmModePageFlip.
This commit forgoes waiting for vblank and flips right away
in those cases. That prevents the hardware from freezing up the screen,
but does mean there will be some visible tearing.
https://bugzilla.gnome.org/show_bug.cgi?id=746042
We can't just destroy and replace the EGL and gbm surfaces while
they are still in use i.e. while there is a pending flip. In fact, in
that case, we were calling gbm_surface_destroy() on a surface that
still had the front buffer locked and then, on the flip handler,
gbm_surface_release_buffer() for a buffer that didn't belong to the
new surface.
Instead, we still allocate new surfaces when requested but they only
replace the old ones on the next swap buffers when we're sure that the
previous flip has been handled and buffers properly released.
Currently the code queries the current msc then tries to approximate the
value of the next msc satisfing the modulus 2 for when to wait. This
introduces some instability as the msc may tick over during the
roundtrip leading to a 32ms wait instead of a 16ms wait. This happens
often enough to cause jerky animations, and affect gnome-shell-perf-tool.
A simpler solution is just use a single roundtrip by using WaitForMsc to
ask the driver to compute the next vblank itself.
Cc: Owen W. Taylor <otaylor@fishsoup.net>
Cc: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Add cogl_texture_pixmap_x11_new_left() and
cogl_texture_pixmap_x11_new_right() (which takes the left texture
as an argument) for texture pixmap rendering with stereo content.
The underlying GLXPixmap is created using a stereo visual and shared
between the left and right textures.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
If we want to show quad-buffer stereo with Cogl, we need to pick an
appropriate fbconfig for creating the CoglOnscreen objects. Add
cogl_onscreen_template_set_stereo_enabled() to indicate whether
stereo support is needed.
Add cogl_framebuffer_get_stereo_mode() to see if a framebuffer was
created with stereo support.
Add cogl_framebuffer_get_stereo_mode() to pick whether to draw to
the left, right, or both buffers.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
An application might for whatever reason want to control a specific output
directly and have cogl only swap the other outputs if any. So add an api that
allows setting a crtc to be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=730536
The surfaceless context extension can be used to bind a context
without a surface. We can use this to avoid creating a dummy surface
when the CoglContext is first created. Otherwise we have to have the
dummy surface so that we can bind it before the first onscreen is
created.
The main awkward part of this patch is that theoretically according to
the GL and GLES spec if you first bind a context without a surface
then the default state for glDrawBuffers is GL_NONE instead of
GL_BACK. In practice Mesa doesn't seem to do this but we need to be
robust against a GL implementation that does. Therefore we track when
the CoglContext is first used with a CoglOnscreen and force the
glDrawBuffers state to be GL_BACK.
There is a further awkward part in that GLES2 doesn't actually have a
glDrawBuffers state but GLES3 does. GLES3 also defaults to GL_NONE in
this case so if GLES3 is available then we have to be sure to set the
state to GL_BACK. As far as I can tell that actually makes GLES3
incompatible with GLES2 because in theory if the application is not
aware of GLES3 then it should be able to assume the draw buffer is
always GL_BACK.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit e5f28f1e75db9bdc4f2688f420a74f908f96cf76)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
cogl/winsys/cogl-winsys-egl-x11.c
Some features that were previously available as an extension in GLES2
are now in core in GLES3 so we should be able to specify that with the
gles_availability mask of COGL_EXT_BEGIN so that GL implementations
advertising GLES3 don't have to additionally advertise the extension
for us to take advantage of it.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit 4d892cd97558da61ba526f947ac0555ebab632d2)
When a new CoglAtlasTexture tries to fit into an existing CoglAtlas
it should make sure the atlas stays valid while it expands.
https://bugzilla.gnome.org/show_bug.cgi?id=728064
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2eec9758f67e9073371c2edd63379324849373c4)
This can happen when we dpms off the output or when login1 takes away
drm master status from our drm fd. In either case, we need to call
the swap notify handler so that the compositor dosn't get stuck waiting
for that notification. The compositor should stop repainting shortly in
both cases, as it's either going into dpms off mode or vt switching away.
https://bugzilla.gnome.org/show_bug.cgi?id=728979
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This environment variable predates the reliable platform detection in mesa
and typically just causes crashes when the specified platform doesn't
match what's passed in. Aside from being unecessary and problematic
it also leaks into the GNOME session, preventing clients from
automatically detecting the wayland platform.
https://bugzilla.gnome.org/show_bug.cgi?id=728978
Reviewed-by: Neil Roberts <neil@linux.intel.com>
