On 21 August 2017 at 15:44, Daniel Stone <dan...@fooishbar.org> wrote: > Hi Emil, > > On 21 August 2017 at 15:18, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 11 July 2017 at 14:27, Emil Velikov <emil.l.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev