linux-kernel - Re: [PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <o1qcCo8e19pmmNe-YJbPkmu4SBrOQ_E3u7eqdrcXUzdBccLtFswL_ARTpbrX9C10tippuy5ieXAsqdf7H47JuT7Hqa1NlizAPqVuRM0kRt4=@emersion.fr>
Date:   Wed, 29 Jun 2022 14:53:49 +0000
From:   Simon Ser <contact@...rsion.fr>
To:     Dennis Tsiang <dennis.tsiang@....com>
Cc:     Pekka Paalanen <ppaalanen@...il.com>,
        Normunds Rieksts <Normunds.Rieksts@....com>, airlied@...ux.ie,
        tzimmermann@...e.de, Liviu Dudau <Liviu.Dudau@....com>,
        linux-kernel@...r.kernel.org,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        christian.koenig@....com, linaro-mm-sig@...ts.linaro.org,
        david.harvey-macaulay@....com, Lisa Wu <lisa.wu@....com>,
        nd <nd@....com>, sumit.semwal@...aro.org,
        linux-media@...r.kernel.org
Subject: Re: [PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

On Wednesday, June 29th, 2022 at 16:46, Dennis Tsiang <dennis.tsiang@....com> 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.