Ville Syrjälä <ville.syrj...@linux.intel.com> writes: > What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
> If its just an srgb version of ARGB8888, then I wouldn't really want it
> in drm_fourcc.h. I expect colorspacy stuff will be handled by various
> crtc/plane properties in the kernel so we don't need to encode that
> stuff into the fb format.
It's not any different from splitting YUV codes from RGB codes; a
different color encoding with the same bitfields. And, for mesa, it's
necessary to differentiate between ARGB and SARGB within the same format
code given how the API is structured. So, we have choices:
1) Let Mesa define it's own fourcc codes and risk future accidental
collisions
2) Rewrite piles of mesa code to split out the color encoding from the
bitfield information and pass it separately.
3) Add "reasonable" format codes like this to the kernel fourcc list.
--
keith.pack...@intel.com
pgpu6mWttBLty.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
