[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190321154745.4o7setv3bucphrsv@flea>
Date: Thu, 21 Mar 2019 16:47:45 +0100
From: Maxime Ripard <maxime.ripard@...tlin.com>
To: Brian Starkey <Brian.Starkey@....com>
Cc: Nicolas Dufresne <nicolas@...fresne.ca>,
Daniel Vetter <daniel.vetter@...el.com>,
David Airlie <airlied@...ux.ie>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Sean Paul <seanpaul@...omium.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Hans Verkuil <hans.verkuil@...co.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
nd <nd@....com>
Subject: Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
On Wed, Mar 20, 2019 at 06:15:54PM +0000, Brian Starkey wrote:
> On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> > All RGB mapping should be surrounded by ifdef, because many (not all)
> > DRM formats represent the order of component when placed in a CPU
> > register, unlike V4L2 which uses memory order. I've pick this one
> > randomly, but this one on most system, little endian, will match
> > V4L2_PIX_FMT_XBGR32. This type of complex mapping can be found in
> > multiple places, notably in GStreamer:
> >
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/sys/kms/gstkmsutils.c#L45
>
> I do sort-of wonder if it's worth trying to switch to common fourccs
> between DRM and V4L2 (and whatever else there is).
>
> The V4L2 formats list is quite incomplete and a little quirky in
> places (V4L2_PIX_FORMAT_XBGR32 and V4L2_PIX_FORMAT_XRGB32 naming
> inconsistency being one. 'X' isn't even next to 'B' in XBGR32).
>
> At least for newly-added formats, not using a common definition
> doesn't make a lot of sense to me. Longer term, I also don't really
> see any downsides to unification.
Eventually, I agree that that his where we should be heading. Moving
the existing formats support to a common place will help with that.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists