Hi Emil, On 21 August 2017 at 15:18, Emil Velikov <[email protected]> wrote: > On 11 July 2017 at 14:27, Emil Velikov <[email protected]> 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. 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. Cheers, Daniel _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
