Conversation
The EGL implementation attaching the front buffer, posting damage, and committing during the call to eglSwapBuffers(WithDamage)() is a well established requirement that EGL Wayland clients currently rely upon, thus should be explicitly documented.
Wayland EGL applications rely on the EGL implementation creating wp_color_management_surface_v1 objects for the associated surface, as doing so may cause protocol errors when the application itself creates them. Document this restriction.
| object with the surface, an acquire and a release point will be associated | ||
| with the surface prior to the commit as well. | ||
|
|
||
| An EGL implementation must not create a wp_color_management_surface_v1 |
There was a problem hiding this comment.
I don't think that's realistic. Don't we need this to implement things like EGL_EXT_gl_colorspace_scrgb_linear properly?
There was a problem hiding this comment.
That sounds like a necessity indeed, unless the application itself handles describing the content, and EGL just generating appropriate pixel values. Would EGL need to manage this state internally, I guess it needs to be specified when exactly it will do so, to not cause conflicts with existing color manager protocol users that uses it to describe EGL content.
There was a problem hiding this comment.
In Vulkan we worked out a design where the PASSTHROUGH colorspace indicated the Vulkan implementation wouldn't create the Wayland object. Perhaps something similar is possible in EGL? I would expect the application isn't using a particular colorspace value currently if it's using the color management protocol directly. I haven't reviewed the EGL HDR/colorspace-related extensions in detail. I think the sRGB/linear colorspace spec has implications on how core rendering to the surface works, but I don't think the others do.
2 participants
EGL_KHR_platform_wayland: Enforce no color management
Wayland EGL applications rely on the EGL implementation creating
wp_color_management_surface_v1 objects for the associated surface, as
doing so may cause protocol errors when the application itself creates
them. Document this restriction.