Hi, On 28 June 2017 at 19:09, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On Wed, Jun 28, 2017 at 10:59 AM, Daniel Stone <dan...@fooishbar.org> wrote: >> i965 tries pretty hard to allocate sRGB images in the pre-DRIImage, >> DRI2 (as in the X11 protocol named 'DRI2') codepath, but this isn't >> used by Wayland, GBM, or DRI3. > > Except that whether you get an sRGB renderbuffer or not is governed by GLX > and EGL and not Wayland/DRI2/DRI3. In one of them (I think it's ES), the > default is to get an sRGB renderbuffer but either is possible with both > independent of how the image comes in. We *do* see it on DRI3 and Wayland > which is why this patch exists in the first place.
Well, that's fairly depressing. So I guess SARGB8 is only used for GLX_ARB_framebuffer_sRGB, and the rest is just magically transforming (ostensibly) _UNORM Mesa formats into _SRGB? intel_gles3_srgb_workaround() is ... quite a thing. >> So no, not for pretty much any externally-visible images AFAICT. Even >> if it were true for scanout, the client would need to tell KMS, so KMS >> could send a HDMI infoframe telling the display. > > But scanout always does sRGB. If you want real UNORM, then you'll have to > add kernel API. I'm kinda confused on this point; the colour transform matrix set up by default is an identity mapping, rather than a degamma-to-linear (ignoring the 16-235 vs. limited dance ...). In theory, if we're sending sRGB, we should inform the sink via an AVI infoframe, but I can't see anywhere we actually do that. Anyway, I don't see this patch making the historical mistake any better or worse, so let's just mentally file it away to bottom out one day and move on. Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
