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
Attachment:
signature.asc
Description: This is a digitally signed message part
