[Mesa-dev] Gallium DRI drivers default GL_READ/WRITE_BUFFER to GL_(BACK|FRONT)_LEFT instead of GL_(BACK|FRONT)

[Brian Paul]

On 12/07/2011 04:31 AM, Jose Fonseca wrote:
> I wrote a testsuite for apitrace, and one of the tests checks the default GL state against a reference, and it is failing on all Gallium DRI drivers because
>
> {
>    parameters: {
>      GL_DRAW_BUFFER: "GL_BACK" ->  "GL_BACK_LEFT",
>      GL_DRAW_BUFFER0: "GL_BACK" ->  "GL_BACK_LEFT",
>      GL_READ_BUFFER: "GL_BACK" ->  "GL_BACK_LEFT",
>    },
> }
>
> This looks like a bug as glDrawBuffer/glReadBuffer manpages are quite clear: GL_BACK on double buffer visual, GL_
>
> And the odd thing is that Mesa gets it right, but st_visual_to_default_buffer() function goes out of its way to put the wrong values and this fixes it
>
> diff --git a/src/mesa/state_tracker/st_manager.c b/src/mesa/state_tracker/st_manager.c
> index d5228d3..c64e175 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -414,6 +414,8 @@ st_visual_to_default_buffer(const struct st_visual *visual,
>      GLenum buf;
>      gl_buffer_index idx;
>
> +   return;
> +
>      statt = visual->render_buffer;
>      /* do nothing if an invalid render buffer is specified */
>      if (statt == ST_ATTACHMENT_INVALID ||
>
>
> No other DRI driver changes these GL_BACK/GL_FRONT values.
>
> Does this st_visual_to_default_buffer() server any purpose?
>
> If it really does then, then at least GL_(BACK|FRONT)_(LEFT|RIGHT should be replaced with GL_(BACK|FRONT) there.


AFAICT, we don't need st_visual_to_default_buffer() at all either.

Mesa always checks the gl_config/visual to determine whether to 
initialize GL_READ/DRAW_BUFFER to GL_FRONT or GL_BACK.  AFAICT, the 
st_manager code initialized the visual correctly so I don't see why 
the st_manager code needs to touch those vars.

Maybe Olv can take a look...

-Brian