On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang <dennis.tsiang@xxxxxxx> wrote: > Thanks for your comments. This is not intended to be used for KMS, where > indeed there would be no difference. This proposal is for other Graphics > APIs such as Vulkan, which requires the application to be explicit > upfront about how they will interpret the data, whether that be UNORM, > UINT .etc. We want to be able to import dma_bufs which create a VkImage > with a "_UINT" VkFormat. However there is currently no explicit mapping > between the DRM fourccs + modifiers combos to "_UINT" VkFormats. One > solution is to encode that into the fourccs, which is what this RFC is > proposing. As a general comment, I don't think it's reasonable to encode all of the VkFormat information inside DRM FourCC. For instance, VkFormat has SRGB/UNORM variants which describe whether pixel values are electrical or optical (IOW, EOTF-encoded or not). Moreover, other APIs may encode different information in their format enums.
