[Mesa-dev] [PATCH 2/2] egl/drm: set the VISUAL_TYPE alongside the VISUAL_ID

[Emil Velikov]

On 21 August 2017 at 15:44, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Emil,
>
> On 21 August 2017 at 15:18, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 11 July 2017 at 14:27, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> According to the EGL_KHR_platform_gbm extension:
>>>
>>>     For each EGLConfig that belongs to the GBM platform, the
>>>     EGL_NATIVE_VISUAL_ID attribute is a GBM color format, such as
>>>     GBM_FORMAT_XRGB8888.
>>>
>>> Which we correctly manage. At the same time the EGL 1.4 spec says
>>>
>>>     If an EGLConfig supports windows then it may have an associated
>>>     native visual. EGL_NATIVE_VISUAL_ID specifies an identifier for this
>>>     visual, and EGL_NATIVE_VISUAL_TYPE specifies its type. If an
>>>     EGLConfig does not support windows, or if there is no associated
>>>     native visual type, then querying EGL_NATIVE_VISUAL_ID will return 0
>>>     and querying EGL_NATIVE_VISUAL_TYPE will return EGL_NONE.
>>>
>>> Based on this, either both of ID and TYPE should be set, or neither.
>>>
>>> [...]
>>
>> Does the above make sense? Should we bother?
>> Admittedly the stable tag could be dropped, since it's not that
>> crucial of a fix.
>
> Did this come up in CTS or similar, or was it just by inspection? I
> don't read 0 to mean 'unset'; if an X11 StaticGray visual gets added
> (admittedly extremely unlikely), that would have a NATIVE_VISUAL_TYPE
> of 0, so there would be precedent for the type being 0.
>
Spotted by observation. I fully agree though - calling it "set" is wrong.
What I should have mentioned is - unique.

> My take on it is that the visual types are defined by the platform,
> and 0 is a perfectly sensible visual type for a platform which does
> not actually have any.
>
Having the exact same visual type for all visual IDs does strikes me
as a bit odd.
That said, the spec does not explicitly forbids it so I guess it should be fine?

-Emil