[libcamera-devel] [PATCH 0/6] cam: add --format option to configure a stream
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Mon Feb 4 19:42:04 CET 2019
Hi Niklas,
On Fri, Feb 01, 2019 at 04:22:00PM +0100, Niklas Söderlund wrote:
> On 2019-01-31 12:06:35 +0200, Laurent Pinchart wrote:
> > On Tue, Jan 29, 2019 at 09:33:32AM +0000, Kieran Bingham wrote:
> >> Hi Niklas,
> >>
> >> Except for a "we're writing an option parser rather than pulling one in"
> >> concern, I don't see anything too wrong with this series and it's a
> >> stand-alone tool (which you currently own :D )
> >>
> >> So I'd say,
> >>
> >> Acked-by: Kieran Bingham <kieran.bingham at ideasonboard.com>
> >>
> >> <edit: a couple of minor notes on 6/6>
> >>
> >> I think creating an opaque object to manage the camera from the
> >> application point of view will give us a lot of benefits to hiding the
> >> internal implementation and shared-ptrs.
> >
> > That's Tomasz's proposal, right ?
>
> To me this is the d-pointer discussion we had in the past and recoded as
> 'Research ABI stability with regard to private data' topic. And if I
> understand Tomasz proposal his view is somewhat aligned whit this, but I
> might have misunderstood.
It's similar in purpose to the d-pointer, yes. Usually a d-pointer will
have the same lifetime as the object that holds it, so this case is
slightly different in the sense that the d-pointer would be shared, but
otherwise it does indeed serve as a way to hide the underlying
implementation.
> >> Then an application can get a single 'unique' ptr - and it's destruction
> >> can handle all clean up on the internal calls.
> >
> > Should that be a std::unique_ptr<>, or just a normal pointer ?
> >
> >> Anyway - Keeping the tool in use and actively developed will help us
> >> develop how the applications will use the library - so I'm all for
> >> getting this series in and developing it as we go.
> >>
> >> On 28/01/2019 00:41, Niklas Söderlund wrote:
> >>> Hi,
> >>>
> >>> This series aims to add a --format option to the cam utility so that it
> >>> can set the format of a stream of a specified camera. To do this in an
> >>> efficient manner a new key=value parser is needed to understand the
> >>> arguments given to the new option, example
> >>>
> >>> cam --camera mycam --format width=800,height=600
> >>>
> >>> This series adds such a parser and then moves on to adding the new
> >>> operation to the cam utility in 6/6. This series depends on [1] for 6/6
> >>> which needs the stream API in the camera object to actually set the
> >>> requested format.
> >>>
> >>> 1. [PATCH v3 0/6] libcamera: add basic support for streams and format
> >>> configuration
> >>>
> >>> Niklas Söderlund (6):
> >>> cam: options: move enum OptionArgument
> >>> cam: options: create a template class for options
> >>> cam: options: return if addOption() succeeds or not
> >>> cam: options: remove OptionsParser::options_
> >>> cam: options: add a key=value parser
> >>> cam: add --format option to configure a stream
> >>>
> >>> src/cam/main.cpp | 107 ++++++++++++++++++++++----
> >>> src/cam/options.cpp | 178 +++++++++++++++++++++++++++++++++++++++-----
> >>> src/cam/options.h | 70 +++++++++++++----
> >>> 3 files changed, 305 insertions(+), 50 deletions(-)
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list