From: Brian Starkey <brian.starkey@arm.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>,
Hans Verkuil <hverkuil@xs4all.nl>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
jonathan.chai@arm.com,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: DRM Format Modifiers in v4l2
Date: Tue, 29 Aug 2017 10:47:01 +0100 [thread overview]
Message-ID: <20170829094701.GB26907@e107564-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKMK7uGaQ+9cZ2PyLkwC06Qpch3AK+Tkr4SZFZVLfUqUFKyygQ@mail.gmail.com>
On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote:
>On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>> 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.
>
>Note on the intel modifers: On most recent platforms (iirc gen9) the
>modifier is well defined and always describes the same byte layout. We
>simply didn't want to rewrite our entire software stack for all the
>old gunk platforms, hence the language. I guess we could/should
>describe the layout in detail, but atm we're the only ones using it.
>
>On your topic of v4l2 encoding the drm fourcc+modifier combo into a
>special v4l fourcc: That's exactly the mismatch I was thinking of.
>There's other examples of v4l2 fourcc being more specific than their
>drm counters (e.g. specific way the different planes are laid out).
I'm not entirely clear on the v4l2 fourccs being more specific than
DRM ones - do you mean e.g. NV12 vs NV12M? Specifically in the case of
multi-planar formats I think it's a non-issue because modifiers are
allowed to alter the number of planes and the meanings of them. Also
V4L2 NV12M is a superset of NV12 - so NV12M would always be able to
describe a DRM NV12 buffer.
I don't see the "special v4l2 format already exists" case as a problem
either. It would be up to any drivers that already have special
formats to decide if they want to also support it via a more generic
modifiers API or not.
The fact is, adding special formats for each combination is
unmanageable - we're talking dozens in the case of our hardware.
Cheers,
-Brian
>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2017-08-29 9:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 15:52 DRM Format Modifiers in v4l2 Brian Starkey
2017-08-21 16:01 ` Daniel Vetter
2017-08-21 16:21 ` Brian Starkey
2017-08-21 16:36 ` Hans Verkuil
2017-08-24 11:14 ` Brian Starkey
2017-08-24 11:37 ` Hans Verkuil
2017-08-24 12:26 ` Brian Starkey
2017-08-25 8:14 ` Hans Verkuil
2017-08-29 9:19 ` Brian Starkey
2017-08-31 14:36 ` Laurent Pinchart
2017-08-28 18:07 ` Nicolas Dufresne
2017-08-28 20:49 ` Daniel Vetter
2017-08-29 9:47 ` Brian Starkey [this message]
2017-08-30 7:50 ` Daniel Vetter
2017-08-30 8:10 ` Hans Verkuil
2017-08-30 9:36 ` Brian Starkey
2017-08-30 9:53 ` Hans Verkuil
2017-08-30 10:32 ` Brian Starkey
2017-08-31 14:51 ` Laurent Pinchart
2017-08-31 15:23 ` Brian Starkey
2017-08-31 14:28 ` Laurent Pinchart
2017-08-31 16:12 ` Nicolas Dufresne
2017-09-01 7:13 ` Laurent Pinchart
2017-09-01 12:43 ` Rob Clark
2017-09-03 9:00 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170829094701.GB26907@e107564-lin.cambridge.arm.com \
--to=brian.starkey@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=jonathan.chai@arm.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=nicolas@ndufresne.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).