<div dir="ltr"><span style="font-size:12.8px">Hi Ilia,</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Setting it correctly initially is more messy.  At least in my use case, we know the context type from EGL_RENDERABLE_TYPE before the framebuffer is created.  We would need to add the context information to the visual used by _mesa_initialize_window_</span><span style="font-size:12.8px">framebuffer.  That requires including main/mtypes.h in the EGL part of the source tree, which nobody else does and leads to build system issues.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">We could also make the change in _mesa_make_current instead of get.c, but once again we'll be flipping the original value.  I'll send a modified patch shortly unless somebody has any other ideas.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 7:55 PM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 27, 2016 at 6:30 PM, Gurchetan Singh<br>
<<a href="mailto:gurchetansingh@chromium.org">gurchetansingh@chromium.org</a>> wrote:<br>
> Hi Ilia,<br>
><br>
> The changes for get.c where prompted by the es3fIntegerStateQueryTests (see<br>
> modules/gles3/functional/es3fIntegerStateQueryTests.cpp in the dEQP tree).<br>
> Specifically, these few lines:<br>
><br>
>>> const GLint validInitialValues[] = {GL_BACK, GL_NONE};<br>
>>> m_verifier->verifyIntegerAnyOf(m_testCtx, GL_READ_BUFFER,<br>
>>> validInitialValues, DE_LENGTH_OF_ARRAY(validInitialValues));<br>
>>> expectError(GL_NO_ERROR);<br>
><br>
> We initially set ColorReadBuffer to GL_FRONT in<br>
> _mesa_initialize_window_framebuffer for single-buffered configs.<br>
<br>
</span>So ... could we initialize it to GL_BACK for GLES and avoid this pain?<br>
Unfortunately I have no idea what the implications of that would be.<br>
<span class=""><br>
><br>
> We could also make sure the context is single-buffered in get.c to further<br>
> avoid bugs.  Let me know if that works for you and I'll send a modified<br>
> patch.<br>
><br>
> I do agree it is a bit hacky ... I'd definitely be interested in alternative<br>
> solutions.<br>
<br>
</span>If you're flipping the value in the getter, you might as well set that<br>
to be the value from the very beginning. However I don't know what the<br>
effects of that are.<br>
<span class="HOEnZb"><font color="#888888"><br>
  -ilia<br>
</font></span></blockquote></div><br></div>