From: Daniel Vetter <daniel@ffwll.ch>
To: Brian Starkey <brian.starkey@arm.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
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: Wed, 30 Aug 2017 09:50:35 +0200 [thread overview]
Message-ID: <20170830075035.ojzhefm3ysqzigkg@phenom.ffwll.local> (raw)
In-Reply-To: <20170829094701.GB26907@e107564-lin.cambridge.arm.com>
On Tue, Aug 29, 2017 at 10:47:01AM +0100, Brian Starkey wrote:
> 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.
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 :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2017-08-30 7:50 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
2017-08-30 7:50 ` Daniel Vetter [this message]
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=20170830075035.ojzhefm3ysqzigkg@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=brian.starkey@arm.com \
--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).