Am Dienstag, den 30.10.2018, 16:52 -0400 schrieb Ilia Mirkin: [snip] > > > } > > > #endif > > > > > > + extensions->EXT_sRGB_write_control = > > > + screen->is_format_supported(screen, > > > PIPE_FORMAT_B8G8R8A8_SRGB, > > > + PIPE_TEXTURE_2D, 0, 0, > > > + (PIPE_BIND_DISPLAY_TARGET | > > > + PIPE_BIND_RENDER_TARGET)); > > > > > > This is kinda a hack because DISPLAY_TARGET has nothing to do with > > sRGB. sRGB is a 3D/framebuffer feature, unrelated to the window > > system. The sRGB property of the format is private within the > > application and is not visible outside of it. The window system > > doesn't care what is and isn't sRGB. I think you are just hiding a > > bug in your driver. > > Yeah, it's unclear to me what GL_EXT_sRGB_write_control does beyond > using a sRGB framebuffer format for a FBO. Either you can handle that > format or you can't... > This is actually just some copy-paste problem, i.e. I took what is used in st_manager.c:st_framebuffer_create to check for sRGB support of the sepcific format used there, adjusted the pipe format to a defined format and cleaned the sample parameters. If this is not needed for some other reason, then I'll just drop it.
Best, Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev