DRM Format Modifiers in v4l2

[Brian Starkey]

On Wed, Aug 30, 2017 at 10:10:01AM +0200, Hans Verkuil wrote:
>On 30/08/17 09:50, Daniel Vetter wrote:
>> On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
>>> The fact is, adding special formats for each combination is
>>> unmanageable - we're talking dozens in the case of our hardware.
>>
>> Hm right, we can just remap the special combos to the drm-fourcc +
>> modifier style. Bonus point if v4l does that in the core so not everyone
>> has to reinvent that wheel :-)
>
>Probably not something we'll do: there are I believe only two drivers that
>are affected (exynos & mediatek), so they can do that in their driver.
>
>Question: how many modifiers will typically apply to a format? I ask
>because I realized that V4L2 could use VIDIOC_ENUMFMT to make the link
>between a fourcc and modifiers:
>
>https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-enum-fmt.html
>
>The __u32 reserved[4] array can be used to provide a bitmask to modifier
>indices (for the integer menu control). It's similar to what drm does,
>except instead of modifiers mapping to fourccs it is the other way around.
>
>This would avoid having to change the modifiers control whenever a new
>format is set and it makes it easy to enumerate all combinations.
>
>But this only works if the total number of modifiers used by a single driver
>is expected to remain small (let's say no more than 64).

In our current (yet to be submitted) description, we've got around a
dozen modifiers for any one format to describe our compression
variants. We have a lot of on/off toggles which leads to combinatorial
expansion, so it can grow pretty quickly (though I am trying to limit
the valid combinations as much as possible).

How about if the mask fills up then VIDIOC_ENUM_FMT can return another
fmtdsc with the same FourCC and different modifier bitmask, where the
second one's modifier bitmask is for the next "N" modifiers?

-Brian
>
>Regards,
>
>	Hans