From patchwork Tue Mar 17 03:52:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Niklas_S=C3=B6derlund?= X-Patchwork-Id: 3131 Return-Path: Received: from bin-mail-out-06.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 7A8EE60416 for ; Tue, 17 Mar 2020 04:53:36 +0100 (CET) X-Halon-ID: cd8797c1-6802-11ea-aa6d-005056917f90 Authorized-sender: niklas@soderlund.pp.se Received: from bismarck.berto.se (p4fca2392.dip0.t-ipconnect.de [79.202.35.146]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPA id cd8797c1-6802-11ea-aa6d-005056917f90; Tue, 17 Mar 2020 04:53:23 +0100 (CET) From: =?utf-8?q?Niklas_S=C3=B6derlund?= To: libcamera-devel@lists.libcamera.org Date: Tue, 17 Mar 2020 04:52:31 +0100 Message-Id: <20200317035239.2697679-1-niklas.soderlund@ragnatech.se> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH v2 0/8] libcamera: PixelFormat: Turn into a class X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 03:53:36 -0000 Hello, This series replaces the PixelFormat definition of a unisgned int with a class implementation that can hold both a FourCC and a set of modifiers. This is important to allow users of libcamera to look at modifiers. This series do not make use of the modifiers, a follow up series that adds RAW capture to the IPU3 will make use of them to describe the IPU3 Bayer format memory layout. I have looked at Laurent's series for V4L2PixelFormat [1] and I agree we should align the interface between the two. I have however not taken all concepts from it (yet). The two outstanding questions for me are 1. operator uint32_t() I agree this looks real nice for V4l2PixelFormat, would it be as nice for PixelFormot which can have modifiers? I have no strong feelings. I feel that if we go for it V4L2PixelFormat::value() and PixelFormat::fourcc() should then be dropped. Two ways to do the same thing can't be good ;-) 2. isValid() Is this good or bad, I can't make up my mind. Yet again the modifiers plays in. How would PixelFormat::isValid() deal with DRM_FORMAT_SRGGB10 without any modifiers to describe the memory layout? 1. [PATCH 0/2] Add a V4L2PixelFormat class Laurent Pinchart (1): libcamera: PixelFormat: Make constructor explicit Niklas Söderlund (7): libcamera: Use PixelFormat instead of unsigned int where appropriate test: v4l2_videodevice: buffer_cache: Use DRM pixel format libcamera: pipeline: vimc: Remove internal usage of ImageFormats libcamera: pipeline: uvcvideo: Translate from V4L2 to DRM pixel formats libcamera: v4l2_videodevice: Remove usage of ImageFormats libcamera: PixelFormat: Turn into a class libcamera: PixelFormat: Mark all function arguments of type PixelFormat as const reference include/libcamera/pixelformats.h | 21 ++++++- include/libcamera/stream.h | 4 +- src/cam/main.cpp | 8 +-- src/gstreamer/gstlibcamera-utils.cpp | 18 +++--- src/libcamera/include/v4l2_videodevice.h | 7 ++- src/libcamera/pipeline/ipu3/ipu3.cpp | 8 +-- src/libcamera/pipeline/rkisp1/rkisp1.cpp | 22 +++---- src/libcamera/pipeline/uvcvideo.cpp | 19 ++++-- src/libcamera/pipeline/vimc.cpp | 20 +++--- src/libcamera/pixelformats.cpp | 77 ++++++++++++++++++++++-- src/libcamera/stream.cpp | 8 +-- src/libcamera/v4l2_videodevice.cpp | 47 +++++++-------- src/qcam/format_converter.cpp | 6 +- src/qcam/format_converter.h | 6 +- src/qcam/viewfinder.cpp | 4 +- src/qcam/viewfinder.h | 6 +- src/v4l2/v4l2_camera.cpp | 2 +- src/v4l2/v4l2_camera.h | 2 +- src/v4l2/v4l2_camera_proxy.cpp | 34 +++++------ src/v4l2/v4l2_camera_proxy.h | 2 +- test/stream/stream_formats.cpp | 24 ++++---- test/v4l2_videodevice/buffer_cache.cpp | 4 +- 22 files changed, 221 insertions(+), 128 deletions(-)