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
