Le jeudi 24 août 2017 à 13:26 +0100, Brian Starkey a écrit :
What I mean was: an application can use the modifier to give buffers from one device to another without needing to understand it.
But a generic video capture application that processes the video itself cannot be expected to know about the modifiers. It's a custom HW specific format that you only use between two HW devices or with software written for that hardware.
Yes, makes sense.
However, in DRM the API lets you get the supported formats for each modifier as-well-as the modifier list itself. I'm not sure how exactly to provide that in a control.
We have support for a 'menu' of 64 bit integers: V4L2_CTRL_TYPE_INTEGER_MENU. You use VIDIOC_QUERYMENU to enumerate the available modifiers.
So enumerating these modifiers would work out-of-the-box.
Right. So I guess the supported set of formats could be somehow enumerated in the menu item string. In DRM the pairs are (modifier + bitmask) where bits represent formats in the supported formats list (commit db1689aa61bd in drm-next). Printing a hex representation of the bitmask would be functional but I concede not very pretty.
The problem is that the list of modifiers depends on the format selected. Having to call S_FMT to obtain this list is quite inefficient.
Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think an other one made it the same way recently, something from Mediatek if I remember. Though, unlike the Intel one, the same modifier does not have various result depending on the hardware revision.
regards, Nicolas