[Mesa-dev] [PATCH RFC 3/3] glsl: Rework builtin_variables.cpp to reduce code duplication.

[Chad Versace]

On 07/12/2013 12:25 PM, Fredrik Höglund wrote:
> On Friday 12 July 2013, Chad Versace wrote:
>> On 07/11/2013 10:18 PM, Paul Berry wrote:
>>> Another possibility that Chad suggested when I was talking to him this
>>> afternoon is to just just return BAD_MATCH if the client supplies the
>>> forward-compatibility flag when requesting a 3.0+ context.  Rationale: Mesa
>>> doesn't really support the forward-compatibility flag anyhow (since the EGL
>>> and GLX front-ends just drop it on the floor), and besides we don't know of
>>> any shipping apps that require it (the flag is intended as a developer aid,
>>> so it's unlikely that published apps rely on it).  I don't have a really
>>> strong opinion about is, so I'll let Chad weigh in if he wants to champion
>>> this alternative.
>>
>> Let's fix Mesa to simply emit EGL_BAD_MATCH if the user requests a forward-
>> compatible context. I don't believe we have the right balance of resources
>> and interest to properly implement and test support for the forward-compatible
>> flag. No one users are asking for it, and it's likely nearly no one will use it.
>> The future may change this situation, but that's a big 'may'.
>
> KWin always sets the forward-compatible bit in 4.11, but it's not too late
> to change that. It appears to be accepted by all implementations and has
> no negative side effects, so there was no compelling reason to leave it
> out in a release build.

For what GL context versions does KWin set the forward-compatible bit?
For 3.0 only? For all versions >= 3.0? For that matter, what context
versions does KWin request?

Why does KWin set the forward-compatible bit? There must be some motivation
for that, other than "the button is there so let's push it".