<br><br>On Wednesday, 18 May 2016, Erik Faye-Lund <<a href="mailto:kusmabite@gmail.com">kusmabite@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 18, 2016 at 1:01 PM, Emil Velikov <<a href="javascript:;" onclick="_e(event, 'cvml', 'emil.l.velikov@gmail.com')">emil.l.velikov@gmail.com</a>> wrote:<br>
> On 18 May 2016 at 09:27, Erik Faye-Lund <<a href="javascript:;" onclick="_e(event, 'cvml', 'kusmabite@gmail.com')">kusmabite@gmail.com</a>> wrote:<br>
>> On Wed, May 18, 2016 at 10:12 AM, Daniel Stone <<a href="javascript:;" onclick="_e(event, 'cvml', 'daniel@fooishbar.org')">daniel@fooishbar.org</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> On 18 May 2016 at 00:00, Ian Romanick <<a href="javascript:;" onclick="_e(event, 'cvml', 'idr@freedesktop.org')">idr@freedesktop.org</a>> wrote:<br>
>>>> On 05/17/2016 09:59 AM, Ben Widawsky wrote:<br>
>>>>> I think you misstated this. It's not invalid to have any other value. It's<br>
>>>>> invalid to not have one of the 3 values, which I suppose is technically possible<br>
>>>>> if you say support ES2, but not ES or GL (for example)<br>
>>>>><br>
>>>>>  "Returns a string describing which client rendering APIs are supported. The<br>
>>>>>   string contains a space-separate list of API names. The list must include at<br>
>>>>>   least one of OpenGL, OpenGL_ES, or OpenVG. These strings correspond<br>
>>>>>   respectively to values EGL_OPENGL_API, EGL_OPENGL_ES_API, and EGL_OPENVG_API<br>
>>>>>   of the eglBindAPI, api argument."<br>
>>>>><br>
>>>>> I am concerned by this change since I genuinely have no clue how EGL clients<br>
>>>>> might currently be depending on this, and as such could I request that you not<br>
>>>>> change the existing behavior (spit out when ES2 or ES3). At the bottom I put an<br>
>>>>> untested version of what i would have done.<br>
>>>><br>
>>>> I think this might be right.  Outside of Mesa sources, I can't find any<br>
>>>> mention of OpenGL_ES2 or OpenGL_ES3 strings anywhere on the Internet.<br>
>>>> At least VLC<br>
>>>> (<a href="http://www.videolan.org/developers/vlc/modules/video_output/egl.c" target="_blank">http://www.videolan.org/developers/vlc/modules/video_output/egl.c</a>) uses<br>
>>>> OpenGL_ES for both OpenGL ES 1.x and 2.x.<br>
>>><br>
>>> Yes, and they'd be foolish not to: the proprietary Mali, PVR and<br>
>>> Vivante drivers don't expose these strings, just OpenGL_ES, OpenGL and<br>
>>> OpenVG. No idea what the proprietary Tegra drivers do, but I'd be<br>
>>> surprised if they were different.<br>
>><br>
>> The proprietary NV driver on Tegra 2 reports "OpenGL_ES2 OpenGL_ES<br>
>> OpenGL OpenVG" for me :/<br>
><br>
> Thanks Erik, I wish you had better news.<br>
><br>
> So perhaps we could keep the ES2/ES3 strings for now, until we check<br>
> with newer tegra 3/4 drivers (perhaps they removed it) or a few other<br>
> programs than VLC ?<br>
><br>
<br>
I also checked with my Tegra 3 device, and it has the same issue.<br>
<br>
But do note that this string seems completely garbage to me: Tegra 2/3<br>
doesn't support full OpenGL, yet they return it in the client query.</blockquote><div>Genuinely curious - have you tried creating/using a OpenGL context or is this an educated guess based on the HW capabilities ?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I have doubts anyone is using this string for anything useful in<br>
the first place.<br>
</blockquote><div>Funny ... I actually used it a few weeks ago, although I did not check for the 2/3 ones.</div><div><br></div><div>On the patch in question - feel free to go either way.</div><div><br></div><div>-Emil</div>