[Piglit] [PATCH] request RGB visual, fixes gbm rendering

[Ilia Mirkin]

On Tue, May 12, 2015 at 2:39 PM, Chad Versace <chad.versace at intel.com> wrote:
> On Tue 12 May 2015, Emil Velikov wrote:
>> On 9 May 2015 at 08:08, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> > GBM presumably defaults to RGB565 otherwise. Not all of these are
>> > required, as some would still work with less precision, but this makes
>> > the tests consistent. At least fp-formats and user-clip were failing
>> > previously.
>> >
>> You're spot on - waffle gbm does default to RGB565 when the
>> red/green/blue/alpha size is zero (the default values set in
>> piglit_winsys_framework.c). Although I'm a bit baffled by the meaning
>> of PIGLIT_GL_VISUAL_RGB - does it imply a 32bit and/or a red_size =
>> green_size = blue_size(d) visual ?
>
> PIGLIT_GL_VISUAL_RGB means "give me a config with at least 1 bit in each
> of the r, g, and b channels". The backend (waffle, glut, whatever) then
> interprets that as it wishes. It does not imply that the channels have
> equal size.
>
> I'm also baffled why, before Ilia's patch, gbm returns a RGB565 config,
> but post-patch returns a RGB888 config. It suspect it's a quirk of
> Mesa's gbm implementation.

To be perfectly honest, I didn't actually verify this. Here's what I
know -- Before: fail; After: pass. That's all I've verified. And I
noticed a bunch of other tests that used front-buffer rendering (and
more importantly, probing) but didn't specify any color config, so I
fixed those up too.

  -ilia