linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).