Ilia Mirkin <imir...@alum.mit.edu> writes:
> I suspect that something like this may be the right thing for the
> intel driver... no reason not to expose sRGB-capable visuals when it
> so happens that alpha == 0. Also probably the same treatment should be
> done for BGR565... sRGB encoding will matter even more there, and from
> the looks of it, all gens support that.
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index cc90efe..75f2cce 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -1003,9 +1003,10 @@ intelCreateBuffer(__DRIscreen * driScrnPriv,
> rgbFormat = MESA_FORMAT_B5G6R5_UNORM;
> else if (mesaVis->sRGBCapable)
> rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
> - else if (mesaVis->alphaBits == 0)
> - rgbFormat = MESA_FORMAT_B8G8R8X8_UNORM;
> - else {
> + else if (mesaVis->alphaBits == 0) {
> + rgbFormat = MESA_FORMAT_B8G8R8X8_SRGB;
> + fb->Visual.sRGBCapable = true;
> + } else {
> rgbFormat = MESA_FORMAT_B8G8R8A8_SRGB;
> fb->Visual.sRGBCapable = true;
> }
Thanks for the suggestion. I assume you didn't want to make this into a
proper patch yourself so I went ahead and did it here:
http://patchwork.freedesktop.org/patch/67844/
Along with the other two patches it doesn't cause any regressions in our
CI system.
I left the 565 format alone because there is no enum for
MESA_FORMAT_B5G6R5_SRGB and it seemed like it's better treated as a
separate issue.
We should also fix the fact that the visuals aren't marked as
sRGB-capable even though they are, but again I think that is a separate
issue.
Regards,
- Neil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
