<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 28, 2017 at 4:06 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Hi,<br>
<br>
On 28 June 2017 at 02:05, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><span class="">> The long answer is that the DRI formats do not specify a colorspace.<br>
<br>
</span>Also, strictly speaking, the DRI_IMAGE_FORMAT_* tokens don't specify a<br>
colourspace, nor do the DRM FourCC tokens. DRI_IMAGE_FOURCC_* is<br>
equivalent to the latter, bar the addition of a special and unique<br>
SARGB8 token, i.e. ARGB8888 with the sRGB transfer function (and<br>
presumably primaries?). The rest are presumed UNORM.<br></blockquote><div><br></div><div>Wha?  What's the difference between SARGB8 and ARGB8888 then?  My understanding was that scanout basically treats everything as sRGB anyway.  Clearly, my sRGB knowledge is imperfect.<br><br></div><div>As for enums, sure, that can probably happen.  GL and ISL both have enums for colorspace that we could re-use.<br><br></div><div>--Jason<br></div></div></div></div>