[Mesa-dev] EGL_EXT_*_drm - primary vs render node (Was Re: [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3))

[Emil Velikov]

On 8 September 2016 at 16:29, James Jones <jajones at nvidia.com> wrote:
> On 09/08/2016 04:30 AM, Emil Velikov wrote:
>>
>> On 7 September 2016 at 19:54, James Jones <jajones at nvidia.com> wrote:
>>>
>>> On 09/07/2016 04:18 AM, Emil Velikov wrote:
>>>>
>>>>
>>>> Hi Mathias,
>>>>
>>>> On 6 September 2016 at 18:32, Mathias Fröhlich
>>>> <Mathias.Froehlich at gmx.net> wrote:
>>>>
>>>>>>  ** EGL_EXT_output_drm
>>>>
>>>>
>>>> Correction - the above should read: EGL_EXT_{device,output}_drm
>>>>
>>>>>>  *** Using/exposing the card or render node
>>>>>>  - Extension is designed with EGL streams in mind (using the
>>>>>> primary/card node) while people expect to use to select the rendering
>>>>>> device.
>>>>>>  - Elaborate on the spec and/or introduce EGL_EXT_output{,_drm}_render
>>>>>> ?
>>>>>>  *** Exposing EGL_EXT_output{,_drm}{,_render} on EGL implementations
>>>>>> supporting both SW and HW devices
>>>>>>  - Elaborate on the spec(s), add new one for SW devices and/or error
>>>>>> type to distinguish between the current errors and SW devices
>>>>>
>>>>>
>>>>> I do not care about anything built on top of EGL_EXT_output_base or
>>>>> EGL_*_stream_*. From my point of view this is beside.
>>>>>
>>>>>
>>>>> What I do care about is EGL_EXT_platform_device.
>>>>>
>>>> That's precisely what, where and why we want to clarify, correct the
>>>> spec or add a new one.
>>>>
>>>> James, Daniel, can we hear your input on the following ?
>>>>
>>>> The way I read the spec(s) EGL_EXT_device_drm can effectively be
>>>> either the card/primary or render node, while EGL_EXT_output_drm must
>>>> be the card one.
>>>> Can/should we restrict the former to render only, do you see any
>>>> implications that will bring ?
>>>> Or should we just roll out another spec for the "render only" case ?
>>>
>>>
>>>
>>> I had assumed EGL_EXT_device_drm's queries refer to the card/primary, and
>>> an
>>> additional extension could add a token to query the render node. When we
>>> initially started drafting the extensions, render nodes were just being
>>> introduced, and I considered adding them as a separate query later, but
>>> we
>>> had no need to identify the render nodes, so I demurred.
>>>
>> From a quick look at the EGL world (both desktop and embedded), looks
>> like the Nvidia drivers are the only ones implementing the extension.
>> Thus one can 'retrofit' the extension to target the render node. If
>> anyone is using EGL_EXT_device_drm yet relying on it to provide KMS
>> device then they're just doing/using it wrong ;-)
>
>
> I'm not sure what you're implying here.  Is it:
>
> 1) Changing the behavior of the extension from what was intended, such that
> the existing query returns the render node path.
>
> 2) Making a backwards-compatible modification to the existing extension by
> adding an additional EGL token (e.g., EGL_DRM_RENDER_DEVICE_FILE_EXT) to
> query the render node path.
>
> (1) won't work.  Even though we're the only one's shipping it, there's a lot
> of code (ours and customers') using it that relies on the current behavior,
> where EGL_DRM_DEVICE_FILE_EXT refers to the modesetting/primary file.
>
So even though the spec clearly says that EGL_EXT_device_drm requires
a DRM driver, yet does not explicitly require KMS, the simple
implementation and all(?) users invalidate this by promoting their own
requirement of KMS ? How unfortunate.

> (2) could be done, but I prefer to avoid it whenever possible.  It leaves
> applications in the situation that they can never be sure the new
> functionality is present, since there is no query in EGL to differentiate
> between extension versions.  When running on older drivers, using the new
> query would fail.
>
> Re-reading your email, I'm a bit worried I might have misunderstood what you
> were referring to, given you said "queries" (plural).  We are talking about
> the single query, EGL_DRM_DEVICE_FILE_EXT, right?  Or were you referring to
> something else [as well]?
>
Your understanding is spot on. I unintentionally toggle between
singular and plural forms.

>>> If that interpretation sounds OK, we can add corresponding clarifications
>>> to
>>> the specifications.
>>>
>> That said, if the above is not possible (please check before throwing
>> the towel) the extra text sounds OK.
>
>
> Let me know what you think given the above.
>
Since the ship (1) has sailed, we'll have to go for plan B - another
extension for the render node.

In order to clear any ambiguity in EGL_EXT_device_drm we need to
"s/DRM driver./DRM driver which support KMS./". With that small change
things should be fine.


Thanks
Emil