st/mesa: make winsys fbo sRGB-capable when supported

The texture formats of winsys fbo are always linear becase the st manager
(st/dri for example) could not know the colorspace used.  But it does not mean
that we cannot make the fbo sRGB-capable.  By

 - setting rb->Visual.sRGBCapable to GL_TRUE when the pipe driver supports the
   format in sRGB colorspace,
 - giving rb an sRGB internal format, and
 - updating code to check rb->Format instead of strb->texture->format,

we should be good.

Fixed bug 75226 for at least llvmpipe and ilo, with no piglit regression.

v2: do not set rb->Visual.sRGBCapable for GLES contexts to avoid surprises

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75226

Reviewed-by: Brian Paul <[email protected]>
Tested-by: Michel Dänzer <[email protected]>

1 files changed, 2 insertions, 2 deletions

diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c b/src/mesa/state_tracker/st_atom_framebuffer.c
index c08d9129739..4c4f839d1d0 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -73,8 +73,8 @@ update_framebuffer_state( struct st_context *st )
       strb = st_renderbuffer(fb->_ColorDrawBuffers[i]);
 
       if (strb) {
-         if (strb->is_rtt ||
-             (strb->texture && util_format_is_srgb(strb->texture->format))) {
+         if (strb->is_rtt || (strb->texture &&
+             _mesa_get_format_color_encoding(strb->Base.Format) == GL_SRGB)) {
             /* rendering to a GL texture, may have to update surface */
             st_update_renderbuffer_surface(st, strb);
          }