From: Brian Starkey <brian.starkey@arm.com>
To: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org,
laurent.pinchart@ideasonboard.com, jonathan.chai@arm.com
Subject: DRM Format Modifiers in v4l2
Date: Mon, 21 Aug 2017 16:52:03 +0100 [thread overview]
Message-ID: <20170821155203.GB38943@e107564-lin.cambridge.arm.com> (raw)
Hi all,
I couldn't find this topic talked about elsewhere, but apologies if
it's a duplicate - I'll be glad to be steered in the direction of a
thread.
We'd like to support DRM format modifiers in v4l2 in order to share
the description of different (mostly proprietary) buffer formats
between e.g. a v4l2 device and a DRM device.
DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and
are a vendor-namespaced 64-bit value used to describe various
vendor-specific buffer layouts. They are combined with a (DRM) FourCC
code to give a complete description of the data contained in a buffer.
The same modifier definition is used in the Khronos EGL extension
EGL_EXT_image_dma_buf_import_modifiers, and is supported in the
Wayland linux-dmabuf protocol.
This buffer information could of course be described in the
vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the
information already defined in drm_fourcc.h. Additionally, there
would be quite a format explosion where a device supports a dozen or
more formats, all of which can use one or more different
layouts/compression schemes.
So, I'm wondering if anyone has views on how/whether this could be
incorporated?
I spoke briefly about this to Laurent at LPC last year, and he
suggested v4l2_control as one approach.
I also wondered if could be added in v4l2_pix_format_mplane - looks
like there's 8 bytes left before it exceeds the 200 bytes, or could go
in the reserved portion of v4l2_plane_pix_format.
Thanks for any thoughts,
-Brian
next reply other threads:[~2017-08-21 15:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 15:52 Brian Starkey [this message]
2017-08-21 16:01 ` DRM Format Modifiers in v4l2 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
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=20170821155203.GB38943@e107564-lin.cambridge.arm.com \
--to=brian.starkey@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jonathan.chai@arm.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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).