On Thu, 2018-11-15 at 13:45 +0100, Gert Wollny wrote:
> @@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
> * format such that util_format_srgb(visual->color_format) can be
> supported
> * by the pipe driver. We still need to advertise the capability
> here.
> *
> - * For GLES, however, sRGB framebuffer write is controlled only
> by the
> - * capability of the framebuffer. There is
> GL_EXT_sRGB_write_control to
> - * give applications the control back, but sRGB write is still
> enabled by
> - * default. To avoid unexpected results, we should not advertise
> the
> - * capability. This could change when we add support for
> - * EGL_KHR_gl_colorspace.
> + * For GLES, however, sRGB framebuffer write is initially only
> controlled
> + * by the capability of the framebuffer, with
> GL_EXT_sRGB_write_control
> + * control is given back to the applications, but
> GL_FRAMEBUFFER_SRGB is
> + * still enabled by default since this is the behaviour when
> + * EXT_sRGB_write_control is not available. Since
> GL_EXT_sRGB_write_control
> + * brings GLES on par with desktop GLs EXT_framebuffer_sRGB, in
> mesa this
> + * is also expressed by using the same extension flag
> */
> - if (_mesa_is_desktop_gl(st->ctx)) {
> + if (st->ctx->Extensions.EXT_framebuffer_sRGB) {
This allows this behavior on OpenGL ES 1.x and 2.0 also, which I don't
think we want...
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
