[Mesa-dev] [PATCH] st/mesa: only mark framebuffer as sRGB capable if Mesa supports the format

[Jose Fonseca]

----- Original Message -----
> ---
>  src/mesa/state_tracker/st_manager.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index 68cb5de..314d342 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -421,8 +421,8 @@ st_framebuffer_create(struct st_context *st,
>     /*
>      * For desktop GL, sRGB framebuffer write is controlled by both the
>      * capability of the framebuffer and GL_FRAMEBUFFER_SRGB.  We should
> -    * advertise the capability when the pipe driver supports it so that
> -    * applications can enable sRGB write when they want to.
> +    * advertise the capability when the pipe driver (and core Mesa) supports
> +    * it so that applications can enable sRGB write when they want to.
>      *
>      * This is not to be confused with GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB.
>      When
>      * the attribute is GLX_TRUE, it tells the st manager to pick a color
> @@ -442,6 +442,7 @@ st_framebuffer_create(struct st_context *st,
>           util_format_srgb(stfbi->visual->color_format);
>  
>        if (srgb_format != PIPE_FORMAT_NONE &&
> +          st_pipe_format_to_mesa_format(srgb_format) != MESA_FORMAT_NONE &&
>            screen->is_format_supported(screen, srgb_format,
>                                        PIPE_TEXTURE_2D,
>                                        stfbi->visual->samples,
>                                        PIPE_BIND_RENDER_TARGET))
> --
> 1.7.10.4
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=RJ4H8Fodtw4bz9feDaZf0Kmfgb1mRzAes7QYuQuJBIg%3D%0A&s=e1505a767e53dc4a2785980ce50be6af8a7158670b1628884cff670d82101d5a
> 


Reviewed-by: Jose Fonseca <jfonseca at vmware.com>