From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support Date: Thu, 11 Apr 2019 17:55:40 +0200 Message-ID: <20190411155540.poquzzx2apa5ahgb@flea> References: <3f5748a6422d2f7eb11601bad297df870ff5952b.camel@ndufresne.ca> <5385672c-cfee-7bc4-9c2e-e4d8d964b748@xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4zlq2z5366q2vxuf" Return-path: Content-Disposition: inline In-Reply-To: <5385672c-cfee-7bc4-9c2e-e4d8d964b748@xs4all.nl> Sender: linux-kernel-owner@vger.kernel.org To: Hans Verkuil Cc: Nicolas Dufresne , Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Mauro Carvalho Chehab , Sakari Ailus , Hans Verkuil , Laurent Pinchart , Thomas Petazzoni , Paul Kocialkowski , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org --4zlq2z5366q2vxuf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Thu, Apr 11, 2019 at 09:38:06AM +0200, Hans Verkuil wrote: > >> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = { > >> .has_alpha = true, > >> }, { > >> .drm_fmt = DRM_FORMAT_RGB565, > >> + .v4l2_fmt = V4L2_PIX_FMT_RGB565, > > > > -> V4L2_PIX_FMT_RGB565X > > > > Was added later, as what you expect is not compatible. > > All these 16-bit V4L2 pixelformats are ancient, but they are (to my knowledge) > correct w.r.t. the documented layout of the bits in memory. I.e., that's what > the hardware will give you. > > I think if there is no equivalence between the drm and v4l2 fourcc's, then > you need two entries in this table, one for drm (v4l2_fmt == 0), one for v4l2 > (drm_fmt == 0). Yeah, that was my plan. I'd definitely expect some formats in V4L2 while not supported by DRM, or the other way around. > >> @@ -473,6 +496,7 @@ static const struct image_format_info formats[] = { > >> .is_yuv = true, > >> }, { > >> .drm_fmt = DRM_FORMAT_NV24, > >> + .v4l2_fmt = V4L2_PIX_FMT_NV24, > > > > For extra fun, the M variant has not been added yet. > > Note that it has been the practice in V4L2 to avoid adding pixelformats unless > they are in use by a V4L2 driver. So that's why some combinations do not exist. > > If we are creating a common library then I think we should change that rule > to: "unless they are in use by a DRM or V4L2 driver". And when new formats are > added, and they exists already for DRM or V4L2, then we should use the same > fourcc for the other subsystem. > > I.e. if pixelformat V4L2_PIX_FMT_FOO was already defined, then add a: > > #define DRM_FORMAT_FOO V4L2_PIX_FMT_FOO > > rather than creating a new fourcc. That makes sense > We could even start looking at redoing the whole scheme in a unified way, but > that's something for the (far) future. Yeah, my secret plan is to have eventually a single fourcc (or even #define) for both DRM and v4l2 for any new format. But don't tell anyone :) > This is already a big step forward. Great, I'll respin this then. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --4zlq2z5366q2vxuf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXK9jfAAKCRDj7w1vZxhR xdJlAQCX/ejxdQlqYsc7uKU3WqAQ58yIuyHgkeKWJ9DIA/fmVAEAx4t6BCOAD9PO 8n2ksoAJZYjJniOKhV/5HHr9/khBhQ4= =66eR -----END PGP SIGNATURE----- --4zlq2z5366q2vxuf--