[Mesa-dev] [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3)

[Mathias Fröhlich]

Hi Emil,

On Tuesday, 6 September 2016 12:29:01 CEST Emil Velikov wrote:
>  * SW EGL implementations - do we have any vendors/implementations
> apart from Mesa ?
I dont think so.
But lets put that beside. The reason for me talking about swrast here was to 
fulfill that part of the EGL_EXT_device_enumeration spec that says that there 
is always at least a single EGLDeviceEXT returned. But see below.

>  * Interaction of ^^ with EGL device extension(s) - update existing
> extensions/introduce new ones
>  ** Should EGL_EXT_device_enumeration expose one/multiple SW devices
>  - no: we need alternative glvnd EGL interface for such cases
>  - yes: implementing EGL_EXT_output_drm on EGL implementations
> supporting both HW and SW devices is close to impossible barring spec
> update
> 
>  ** EGL_EXT_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.

>  * Systems with fb only, disabled render nodes and/or alike.
> EGL implementations (in our case the libdrm API provides all the info
> about available DRM devices) can effectively detect the presence of
> HW/SW devices and expose relevant extensions.
> Note: The presence does not and _cannot_ imply that one will always
> succeed using each device.
So you are saying, on a system without drm device we should return a more or 
less dead single EGLDeviceEXT from eglQueryDevicesEXT(...).
Then after that in the call to
eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, EGLDeviceEXT,...)
we just return EGL_NO_DISPLAY.
Which should be ok because of EGL_EXT_platform_base.txt:

------------------
Additions to the EGL 1.4 Specification
[...]
eglGetPlatformDisplayEXT(platform, native_display, ...)
[...]
If <platform> is valid but no display matching <native_display> is
available, then EGL_NO_DISPLAY is returned; no error condition is raised
in this case.
------------------

That seems to work without the need to play with a software rasterizer to 
fulfill the spec.
And yes, I was under the impression that once I have an EGLDeviceEXT in my 
hands I should get a valid EGLDisplay via eglGetPlatformDisplayEXT - which is 
obviously not the case. Of course all that with the presence of the required 
extensions.

Thanks

Mathias