linux-kernel - Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)

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: <8dc44cc4-b107-a384-02fa-2b5ec0d61c3b@collabora.com>
Date:   Tue, 8 Nov 2022 17:58:16 +0300
From:   Dmitry Osipenko <dmitry.osipenko@...labora.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Hsia-Jun Li <Randy.Li@...aptics.com>,
        Helen Koike <helen.koike@...labora.com>, mchehab@...nel.org,
        hans.verkuil@...co.com, sakari.ailus@....fi,
        boris.brezillon@...labora.com, hiroh@...omium.org,
        nicolas@...fresne.ca, Brian.Starkey@....com, kernel@...labora.com,
        narmstrong@...libre.com, linux-kernel@...r.kernel.org,
        frkoenig@...omium.org, stanimir.varbanov@...aro.org,
        tfiga@...omium.org, Hans Verkuil <hverkuil@...all.nl>,
        linux-media@...r.kernel.org,
        "frkoenig@...omium.org" <frkoenig@...omium.org>
Subject: Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify
 single/multi-planar handling (and more)

On 11/7/22 11:30, Laurent Pinchart wrote:
> On Mon, Nov 07, 2022 at 01:11:32AM +0300, Dmitry Osipenko wrote:
>> On 11/5/22 18:19, Hsia-Jun Li wrote:
>>> Hello Helen
>>>
>>> I didn't see any updates from V6 and V7-WIP in your repo. That is what I
>>> need to for our complex tile formats in our platform.
>>>
>>> Any future plane here?
>>>
>>> Besides I have some ideas on these patches.
>>
>> I was looking into updating this patchset few months ago and the biggest
>> blocker was the absence of immediate upstream user for this new UAPI.
>> What your platform is? Is the driver stack completely opensource?
> 
> libcamera could be a good place to test (part of) this API in userspace.
> We could really do with the data offset feature for instance.

Since we don't have a user for the new UAPI right now, perhaps we can
put the new UAPI behind the staging Kconfig until it will get a
real/production user.

On the other hand, I had unpleasant experience with having UAPI gated by
staging Kconfig for other kernel subsystem in a sense that it
permanently stays a staging UAPI because nobody has time for unstaging it.

I see a common demand in this new UAPI which only becomes stronger over
time. Won't hurt to refresh this patchset. I had a rebased version
locally, but likely it needs to be rebased again. Will try to allocate
time for this.

-- 
Best regards,
Dmitry