[libcamera-devel,v3,1/2] lc-compliance: Add a libcamera compliance tool

11543 diff mbox series

Add a compliance tool to ease testing of cameras. In contrast to the
unit-tests under test/ that aims to test the internal components of
libcamera the compliance tool aims to test application use-cases and to
some extend the public API.

This change adds the boilerplate code of a simple framework for the
creation of tests. The tests aim both to demonstrate the tool and to
catch real problems. The tests added are:

 - Test that if one queues exactly N requests to a camera exactly N
   requests are eventually completed.

 - Test that a configured camera can be started and stopped multiple
   times in an attempt to exercise cleanup code paths otherwise not
   often tested with 'cam' for example.

Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
---
* Changes since v1
- Improve language in commit message and comments.
- Test all roles as they may exercise different code paths in the
  pipeline.
- Move SimpleCapture to its own .cpp/.h files.

* Changes since v2
- Fold in a use-after-free bug fix from Kieran, thanks!
---
 src/lc-compliance/main.cpp           | 139 +++++++++++++++++++++++++
 src/lc-compliance/meson.build        |  25 +++++
 src/lc-compliance/results.cpp        |  75 ++++++++++++++
 src/lc-compliance/results.h          |  45 ++++++++
 src/lc-compliance/simple_capture.cpp | 149 +++++++++++++++++++++++++++
 src/lc-compliance/simple_capture.h   |  54 ++++++++++
 src/lc-compliance/single_stream.cpp  |  75 ++++++++++++++
 src/lc-compliance/tests.h            |  16 +++
 src/meson.build                      |   2 +
 9 files changed, 580 insertions(+)
 create mode 100644 src/lc-compliance/main.cpp
 create mode 100644 src/lc-compliance/meson.build
 create mode 100644 src/lc-compliance/results.cpp
 create mode 100644 src/lc-compliance/results.h
 create mode 100644 src/lc-compliance/simple_capture.cpp
 create mode 100644 src/lc-compliance/simple_capture.h
 create mode 100644 src/lc-compliance/single_stream.cpp
 create mode 100644 src/lc-compliance/tests.h

Hi Niklas,

Thank you for the patch.

On Wed, Mar 10, 2021 at 04:44:13PM +0100, Niklas Söderlund wrote:
> Add a compliance tool to ease testing of cameras. In contrast to the
> unit-tests under test/ that aims to test the internal components of
> libcamera the compliance tool aims to test application use-cases and to
> some extend the public API.

s/extend/extent/

> This change adds the boilerplate code of a simple framework for the
> creation of tests. The tests aim both to demonstrate the tool and to
> catch real problems. The tests added are:
> 
>  - Test that if one queues exactly N requests to a camera exactly N
>    requests are eventually completed.

This is an ongoing discussion, but not a reason to delay merging this
series. We can always change the tests if we decide to reconsider this
behaviour.

>  - Test that a configured camera can be started and stopped multiple
>    times in an attempt to exercise cleanup code paths otherwise not
>    often tested with 'cam' for example.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>

You'll find lots of comments below. Not all of them need to be addressed
now. Small and uncontroversial issues could be fixed in v4, while other
issues can be addressed later. Appropriate \todo comments would be
useful to ensure we don't forget about them.

> ---
> * Changes since v1
> - Improve language in commit message and comments.
> - Test all roles as they may exercise different code paths in the
>   pipeline.
> - Move SimpleCapture to its own .cpp/.h files.
> 
> * Changes since v2
> - Fold in a use-after-free bug fix from Kieran, thanks!
> ---
>  src/lc-compliance/main.cpp           | 139 +++++++++++++++++++++++++
>  src/lc-compliance/meson.build        |  25 +++++
>  src/lc-compliance/results.cpp        |  75 ++++++++++++++
>  src/lc-compliance/results.h          |  45 ++++++++
>  src/lc-compliance/simple_capture.cpp | 149 +++++++++++++++++++++++++++
>  src/lc-compliance/simple_capture.h   |  54 ++++++++++
>  src/lc-compliance/single_stream.cpp  |  75 ++++++++++++++
>  src/lc-compliance/tests.h            |  16 +++

I still wonder if we should reorganize test/ and store lc-compliance
there, but this can be handled later if desired.

>  src/meson.build                      |   2 +
>  9 files changed, 580 insertions(+)
>  create mode 100644 src/lc-compliance/main.cpp
>  create mode 100644 src/lc-compliance/meson.build
>  create mode 100644 src/lc-compliance/results.cpp
>  create mode 100644 src/lc-compliance/results.h
>  create mode 100644 src/lc-compliance/simple_capture.cpp
>  create mode 100644 src/lc-compliance/simple_capture.h
>  create mode 100644 src/lc-compliance/single_stream.cpp
>  create mode 100644 src/lc-compliance/tests.h
> 
> diff --git a/src/lc-compliance/main.cpp b/src/lc-compliance/main.cpp
> new file mode 100644
> index 0000000000000000..e1cbce7eac3df2bc
> --- /dev/null
> +++ b/src/lc-compliance/main.cpp
> @@ -0,0 +1,139 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * main.cpp - lc-compliance - The libcamera compliance tool
> + */
> +
> +#include <iomanip>
> +#include <iostream>
> +#include <string.h>
> +
> +#include <libcamera/libcamera.h>
> +
> +#include "../cam/options.h"

Also not a blocker, but should we move options.h and options.cpp to
src/???/ ? This is the third tool that uses the option parser.

> +#include "tests.h"
> +
> +using namespace libcamera;
> +
> +class Harness
> +{
> +public:
> +	Harness();
> +	~Harness();
> +
> +	int exec(int argc, char **argv);

My Qt bias would push me to pass argc and argv to the constructor, and
turn exec() into a function that takes no argument. It won't have much
influence on anything.

Or maybe parsing arguments in main(), and passing the
OptionsParser::Options to the constructor of the Harness class ? It may
make error handling for argument parsing easier.

> +
> +private:
> +	enum {
> +		OptCamera = 'c',
> +		OptHelp = 'h',
> +	};
> +
> +	int parseOptions(int argc, char **argv);
> +	int init(int argc, char **argv);
> +
> +	OptionsParser::Options options_;
> +	std::unique_ptr<CameraManager> cm_;
> +	std::shared_ptr<Camera> camera_;
> +};
> +
> +Harness::Harness()
> +{
> +	cm_ = std::make_unique<CameraManager>();
> +}
> +
> +Harness::~Harness()
> +{
> +	if (camera_) {
> +		camera_->release();
> +		camera_.reset();
> +	}
> +
> +	cm_->stop();
> +}
> +
> +int Harness::exec(int argc, char **argv)
> +{
> +	int ret = init(argc, argv);
> +	if (ret)
> +		return ret;
> +
> +	std::vector<Results> results;
> +
> +	results.push_back(testSingleStream(camera_));
> +
> +	for (const Results &result : results) {
> +		ret = result.summary();
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +int Harness::init(int argc, char **argv)
> +{
> +	int ret = parseOptions(argc, argv);
> +	if (ret < 0)
> +		return ret;

Maybe

	if (ret == -EINTR)
		return 0;
	if (ret < 0)
		return ret;

? Specifying the help option should result in immediate termination, but
not with EXIT_FAILURE.

> +
> +	ret = cm_->start();
> +	if (ret) {
> +		std::cout << "Failed to start camera manager: "
> +			  << strerror(-ret) << std::endl;
> +		return ret;
> +	}
> +
> +	if (!options_.isSet(OptCamera)) {
> +		std::cout << "No camera specified, available cameras:" << std::endl;
> +		for (const std::shared_ptr<Camera> &cam : cm_->cameras())
> +			std::cout << "- " << cam.get()->id() << std::endl;

You could move this to a separate listCameras() function, as it's also
useful below.

> +		return -ENODEV;
> +	}
> +
> +	const std::string &cameraId = options_[OptCamera];
> +	camera_ = cm_->get(cameraId);
> +	if (!camera_) {
> +		std::cout << "Camera " << cameraId << " not found, available cameras:" << std::endl;
> +		for (const std::shared_ptr<Camera> &cam : cm_->cameras())
> +			std::cout << "- " << cam.get()->id() << std::endl;
> +		return -ENODEV;
> +	}
> +
> +	if (camera_->acquire()) {
> +		std::cout << "Failed to acquire camera" << std::endl;
> +		return -EINVAL;
> +	}
> +
> +	std::cout << "Using camera " << cameraId << std::endl;
> +
> +	return 0;
> +}
> +
> +int Harness::parseOptions(int argc, char **argv)
> +{
> +	OptionsParser parser;
> +	parser.addOption(OptCamera, OptionString,
> +			 "Specify which camera to operate on, by id", "camera",
> +			 ArgumentRequired, "camera");
> +	parser.addOption(OptHelp, OptionNone, "Display this help message",
> +			 "help");
> +
> +	options_ = parser.parse(argc, argv);
> +	if (!options_.valid())
> +		return -EINVAL;
> +
> +	if (options_.empty() || options_.isSet(OptHelp)) {
> +		parser.usage();
> +		return options_.empty() ? -EINVAL : -EINTR;
> +	}

Should we drop the empty check here ? I assume it's here because the
camera option is mandatory. That's enforced by init(), and it's actually
impossible to get init() to list the cameras, as if the camera option
isn't specified, the check here will return an error.

> +
> +	return 0;
> +}
> +
> +int main(int argc, char **argv)
> +{
> +	Harness harness;
> +	return harness.exec(argc, argv) ? EXIT_FAILURE : 0;

s/0/EXIT_SUCCESS/ ?

> +}
> diff --git a/src/lc-compliance/meson.build b/src/lc-compliance/meson.build
> new file mode 100644
> index 0000000000000000..68164537c1055f28
> --- /dev/null
> +++ b/src/lc-compliance/meson.build
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: CC0-1.0
> +
> +libevent = dependency('libevent_pthreads', required : false)

If desired, you could move this from src/cam/meson.build to
src/meson.build to avoid finding the dependency twice. Up to you.

> +
> +if not libevent.found()
> +    warning('libevent_pthreads not found, \'lc-compliance\' application will not be compiled')
> +    subdir_done()
> +endif
> +
> +lc_compliance_sources = files([
> +    '../cam/event_loop.cpp',

Another candidate for src/???/ :-)

> +    '../cam/options.cpp',
> +    'main.cpp',
> +    'results.cpp',
> +    'simple_capture.cpp',
> +    'single_stream.cpp',
> +])
> +
> +lc_compliance  = executable('lc-compliance', lc_compliance_sources,
> +                  dependencies : [
> +                      libatomic,
> +                      libcamera_dep,
> +                      libevent,
> +                  ],
> +                  install : true)
> diff --git a/src/lc-compliance/results.cpp b/src/lc-compliance/results.cpp
> new file mode 100644
> index 0000000000000000..8c42eb2d6822aa60
> --- /dev/null
> +++ b/src/lc-compliance/results.cpp
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * results.cpp - Test result aggregator
> + */
> +
> +#include "results.h"
> +
> +#include <iostream>
> +
> +void Results::add(const Result &result)
> +{
> +	if (result.first == Pass)
> +		passed_++;
> +	else if (result.first == Fail)
> +		failed_++;
> +	else if (result.first == Skip)
> +		skipped_++;
> +
> +	printResult(result);
> +}
> +
> +void Results::add(Status status, const std::string &message)
> +{
> +	add({ status, message });
> +}
> +
> +void Results::fail(const std::string &message)
> +{
> +	add(Fail, message);
> +}
> +
> +void Results::pass(const std::string &message)
> +{
> +	add(Pass, message);
> +}
> +
> +void Results::skip(const std::string &message)
> +{
> +	add(Skip, message);
> +}
> +
> +int Results::summary() const
> +{
> +	if (failed_ + passed_ + skipped_ != planned_) {
> +		std::cout << "Planned and executed number of tests differ "
> +			  << failed_ + passed_ + skipped_ << " executed "
> +			  << planned_ << " planned" << std::endl;
> +
> +		return -EINVAL;
> +	}
> +
> +	std::cout << planned_ << " tests executed, "
> +		  << passed_ << " tests passed, "
> +		  << skipped_ << " tests skipped and "
> +		  << failed_ << " tests failed " << std::endl;
> +
> +	return 0;
> +}
> +
> +void Results::printResult(const Result &result)
> +{
> +	std::string prefix;
> +
> +	/* \todo Make parsable as TAP. */
> +	if (result.first == Pass)
> +		prefix = "PASS";
> +	else if (result.first == Fail)
> +		prefix = "FAIL";
> +	else if (result.first == Skip)
> +		prefix = "SKIP";
> +
> +	std::cout << "- " << prefix << " - " << result.second << std::endl;

Maybe s/" - "/": "/ ? (That's the second one, after the prefix)

> +}
> diff --git a/src/lc-compliance/results.h b/src/lc-compliance/results.h
> new file mode 100644
> index 0000000000000000..a02fd5ab46edd62c
> --- /dev/null
> +++ b/src/lc-compliance/results.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * results.h - Test result aggregator
> + */
> +#ifndef __LC_COMPLIANCE_RESULTS_H__
> +#define __LC_COMPLIANCE_RESULTS_H__
> +
> +#include <string>

#include <utility>

for std::pair.

> +
> +class Results
> +{
> +public:
> +	enum Status {
> +		Fail,
> +		Pass,
> +		Skip,
> +	};
> +
> +	using Result = std::pair<Status, std::string>;
> +
> +	Results(unsigned int planned)
> +		: planned_(planned), passed_(0), failed_(0), skipped_(0)
> +	{
> +	}
> +
> +	void add(const Result &result);
> +	void add(Status status, const std::string &message);
> +	void fail(const std::string &message);
> +	void pass(const std::string &message);
> +	void skip(const std::string &message);

I foresee code sharing with test/ in the future (resisting the urge to
give it a go myself already :-)). How about adding a \todo somewhere ?
We don't have to reinvent the wheel, we could use an existing test
framework if there's one that fits our needs.

> +
> +	int summary() const;
> +
> +private:
> +	void printResult(const Result &result);
> +
> +	unsigned int planned_;
> +	unsigned int passed_;
> +	unsigned int failed_;
> +	unsigned int skipped_;
> +};
> +
> +#endif /* __LC_COMPLIANCE_RESULTS_H__ */
> diff --git a/src/lc-compliance/simple_capture.cpp b/src/lc-compliance/simple_capture.cpp
> new file mode 100644
> index 0000000000000000..fac8db379118efbd
> --- /dev/null
> +++ b/src/lc-compliance/simple_capture.cpp
> @@ -0,0 +1,149 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * simple_capture.cpp - Simple capture helper
> + */
> +
> +#include "simple_capture.h"
> +
> +using namespace libcamera;
> +
> +SimpleCapture::SimpleCapture(std::shared_ptr<Camera> camera)
> +	: camera_(camera), allocator_(std::make_unique<FrameBufferAllocator>(camera))
> +{
> +}
> +
> +SimpleCapture::~SimpleCapture()
> +{
> +}
> +
> +Results::Result SimpleCapture::configure(StreamRole role)
> +{
> +	config_ = camera_->generateConfiguration({ role });
> +
> +	if (config_->validate() != CameraConfiguration::Valid) {
> +		config_.reset();
> +		return { Results::Fail, "Configuration not valid" };
> +	}
> +
> +	if (camera_->configure(config_.get())) {
> +		config_.reset();
> +		return { Results::Fail, "Failed to configure camera" };
> +	}
> +
> +	return { Results::Pass, "Configure camera" };
> +}

Is returning a Result here the best option. Shouldn't test results be
constructed by tests, and helper classes return statuses that let tests
decide what to do ? In particular, the success message generated by this
function will never be used, as success applies to a full test, not to
an invidual step.

On the other hand, the helper classes have the most detailed knowledge
about the errors they can encounter. I'm not sure what would be best. I
wonder if this could be a valid use case for using exceptions. It would
allow writing tests with assert-like functions. For instance, the code
below that tests

	if (captureCount_ != captureLimit_)
		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };

could be replaced with a

	failIfNotEqual(captureCount_, captureLimit, "request(s)");

which would generate the message automatically.

> +
> +Results::Result SimpleCapture::start()
> +{
> +	Stream *stream = config_->at(0).stream();
> +	if (allocator_->allocate(stream) < 0)
> +		return { Results::Fail, "Failed to allocate buffers" };
> +
> +	if (camera_->start())
> +		return { Results::Fail, "Failed to start camera" };
> +
> +	camera_->requestCompleted.connect(this, &SimpleCapture::requestComplete);
> +
> +	return { Results::Pass, "Started camera" };
> +}
> +
> +Results::Result SimpleCapture::stop()
> +{
> +	Stream *stream = config_->at(0).stream();
> +
> +	camera_->stop();
> +
> +	camera_->requestCompleted.disconnect(this, &SimpleCapture::requestComplete);
> +
> +	allocator_->free(stream);
> +
> +	return { Results::Pass, "Stopped camera" };

Generically speaking, should this kind of function be made idempotent,
and be called from destructors ? It would make error handling easier.

> +}
> +
> +/* SimpleCaptureBalanced */
> +
> +SimpleCaptureBalanced::SimpleCaptureBalanced(std::shared_ptr<Camera> camera)
> +	: SimpleCapture(camera)
> +{
> +}
> +
> +Results::Result SimpleCaptureBalanced::capture(unsigned int numRequests)
> +{
> +	Results::Result ret = start();
> +	if (ret.first != Results::Pass)
> +		return ret;
> +
> +	Stream *stream = config_->at(0).stream();
> +	const std::vector<std::unique_ptr<FrameBuffer>> &buffers = allocator_->buffers(stream);
> +
> +	/* No point in testing less requests then the camera depth. */
> +	if (buffers.size() > numRequests) {
> +		/* Cache buffers.size() before we destroy it in stop() */
> +		int buffers_size = buffers.size();
> +		stop();
> +
> +		return { Results::Skip, "Camera needs " + std::to_string(buffers_size)
> +			+ " requests, can't test only " + std::to_string(numRequests) };

This makes me wonder what the granularity of a test should be. What is
"one test", should it be a call to this function with a given number of
buffers, or one call to testSingleStream() ? I'm leaning towards the
later, defining a test as something that can be selected in a test plan.
I can imagine selecting testSingleStream() through a command line
argument (or through a configuration file), going for a smaller
granularity doesn't seem too useful. We need to log the status of
individual steps in a test, but at the top (and TAP) level, I'd limit it
to the higher level.

> +	}
> +
> +	queueCount_ = 0;
> +	captureCount_ = 0;
> +	captureLimit_ = numRequests;
> +
> +	/* Queue the recommended number of reqeuests. */
> +	std::vector<std::unique_ptr<libcamera::Request>> requests;
> +	for (const std::unique_ptr<FrameBuffer> &buffer : buffers) {
> +		std::unique_ptr<Request> request = camera_->createRequest();
> +		if (!request) {
> +			stop();
> +			return { Results::Fail, "Can't create request" };
> +		}
> +
> +		if (request->addBuffer(stream, buffer.get())) {
> +			stop();
> +			return { Results::Fail, "Can't set buffer for request" };
> +		}
> +
> +		if (queueRequest(request.get()) < 0) {
> +			stop();
> +			return { Results::Fail, "Failed to queue request" };
> +		}
> +
> +		requests.push_back(std::move(request));
> +	}
> +
> +	/* Run capture session. */
> +	loop_ = new EventLoop();
> +	loop_->exec();
> +	stop();
> +	delete loop_;

Should we construct the event loop in the constructor of the base class,
and delete it in its destructor ?

> +
> +	if (captureCount_ != captureLimit_)
> +		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };

This is a very long line.

> +
> +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests" };
> +}
> +
> +int SimpleCaptureBalanced::queueRequest(Request *request)
> +{
> +	queueCount_++;
> +	if (queueCount_ > captureLimit_)
> +		return 0;
> +
> +	return camera_->queueRequest(request);
> +}
> +
> +void SimpleCaptureBalanced::requestComplete(Request *request)
> +{
> +	captureCount_++;
> +	if (captureCount_ >= captureLimit_) {
> +		loop_->exit(0);
> +		return;
> +	}
> +
> +	request->reuse(Request::ReuseBuffers);
> +	if (queueRequest(request))
> +		loop_->exit(-EINVAL);
> +}
> diff --git a/src/lc-compliance/simple_capture.h b/src/lc-compliance/simple_capture.h
> new file mode 100644
> index 0000000000000000..3a6afc538c623050
> --- /dev/null
> +++ b/src/lc-compliance/simple_capture.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * simple_capture.h - Simple capture helper
> + */
> +#ifndef __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> +#define __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> +
> +#include <memory>
> +
> +#include <libcamera/libcamera.h>
> +
> +#include "../cam/event_loop.h"
> +#include "results.h"
> +
> +class SimpleCapture
> +{
> +public:
> +	Results::Result configure(libcamera::StreamRole role);
> +
> +protected:
> +	SimpleCapture(std::shared_ptr<libcamera::Camera> camera);

You can pass a libcamera::Camera * as a borrowed reference here, as the
caller guarantees that the reference stays valid for the lifetime of
this class.

> +	virtual ~SimpleCapture();
> +
> +	Results::Result start();
> +	Results::Result stop();
> +
> +	virtual void requestComplete(libcamera::Request *request) = 0;
> +
> +	EventLoop *loop_;
> +
> +	std::shared_ptr<libcamera::Camera> camera_;
> +	std::unique_ptr<libcamera::FrameBufferAllocator> allocator_;
> +	std::unique_ptr<libcamera::CameraConfiguration> config_;
> +};
> +
> +class SimpleCaptureBalanced : public SimpleCapture
> +{
> +public:
> +	SimpleCaptureBalanced(std::shared_ptr<libcamera::Camera> camera);
> +
> +	Results::Result capture(unsigned int numRequests);
> +
> +private:
> +	int queueRequest(libcamera::Request *request);
> +	void requestComplete(libcamera::Request *request) override;
> +
> +	unsigned int queueCount_;
> +	unsigned int captureCount_;
> +	unsigned int captureLimit_;
> +};
> +
> +#endif /* __LC_COMPLIANCE_SIMPLE_CAPTURE_H__ */
> diff --git a/src/lc-compliance/single_stream.cpp b/src/lc-compliance/single_stream.cpp
> new file mode 100644
> index 0000000000000000..0ed6f5dcfb5a516d
> --- /dev/null
> +++ b/src/lc-compliance/single_stream.cpp
> @@ -0,0 +1,75 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * single_stream.cpp - Test a single camera stream
> + */
> +
> +#include <iostream>
> +
> +#include "simple_capture.h"
> +#include "tests.h"
> +
> +using namespace libcamera;
> +
> +Results::Result testRequestBalance(std::shared_ptr<Camera> camera,
> +				   StreamRole role, unsigned int startCycles,
> +				   unsigned int numRequests)
> +{
> +	SimpleCaptureBalanced capture(camera);
> +
> +	Results::Result ret = capture.configure(role);
> +	if (ret.first != Results::Pass)
> +		return ret;
> +
> +	for (unsigned int starts = 0; starts < startCycles; starts++) {
> +		ret = capture.capture(numRequests);
> +		if (ret.first != Results::Pass)
> +			return ret;
> +	}
> +
> +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests with " + std::to_string(startCycles) + " start cycles" };

That's a very long line.

> +}
> +
> +Results testSingleStream(std::shared_ptr<Camera> camera)

Same here, you can pass a borrowed reference as a pointer.

> +{
> +	const std::vector<std::pair<std::string, StreamRole>> roles = {
> +		{ "raw", Raw },
> +		{ "still", StillCapture },
> +		{ "video", VideoRecording },
> +		{ "viewfinder", Viewfinder },
> +	};
> +	const std::vector<unsigned int> numRequests = { 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 };

Should both be static const ?

I'm tempted to generate the fibonacci suite at runtime ;-) Totally
overkill of course.

> +
> +	Results results(numRequests.size() * roles.size() * 2);
> +
> +	if (!camera)
> +		return results;
> +

Is this needed, or can we assume the caller will give us a valid camera
?

> +	for (const auto &role : roles) {
> +		std::cout << "= Test role " << role.first << std::endl;
> +		/*
> +		 * Test single capture cycles
> +		 *
> +		 * Makes sure the camera completes the exact number of requests queued.
> +		 * Example failure is a camera that needs N+M requests queued to
> +		 * complete N requests to the application.
> +		 */
> +		std::cout << "* Test single capture cycles" << std::endl;
> +		for (unsigned int num : numRequests)
> +			results.add(testRequestBalance(camera, role.second, 1, num));
> +
> +		/*
> +		 * Test multiple start/stop cycles
> +		 *
> +		 * Makes sure the camera supports multiple start/stop cycles.
> +		 * Example failure is a camera that does not clean up correctly in its
> +		 * error path but is only tested by single-capture applications.
> +		 */
> +		std::cout << "* Test multiple start/stop cycles" << std::endl;
> +		for (unsigned int num : numRequests)
> +			results.add(testRequestBalance(camera, role.second, 3, num));
> +	}
> +
> +	return results;
> +}
> diff --git a/src/lc-compliance/tests.h b/src/lc-compliance/tests.h
> new file mode 100644
> index 0000000000000000..396605214e4b8980
> --- /dev/null
> +++ b/src/lc-compliance/tests.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2020, Google Inc.
> + *
> + * tests.h - Test modules
> + */
> +#ifndef __LC_COMPLIANCE_TESTS_H__
> +#define __LC_COMPLIANCE_TESTS_H__
> +
> +#include <libcamera/libcamera.h>
> +
> +#include "results.h"
> +
> +Results testSingleStream(std::shared_ptr<libcamera::Camera> camera);
> +
> +#endif /* __LC_COMPLIANCE_TESTS_H__ */
> diff --git a/src/meson.build b/src/meson.build
> index c908b0675773301d..a8a6a572e4cf9482 100644
> --- a/src/meson.build
> +++ b/src/meson.build
> @@ -20,6 +20,8 @@ subdir('android')
>  subdir('libcamera')
>  subdir('ipa')
>  
> +subdir('lc-compliance')
> +
>  subdir('cam')
>  subdir('qcam')
>

Hi Laurent,

Thanks for your feedback.

On 2021-03-14 22:47:17 +0200, Laurent Pinchart wrote:

<snip>

> > diff --git a/src/lc-compliance/simple_capture.cpp 
> > b/src/lc-compliance/simple_capture.cpp
> > new file mode 100644
> > index 0000000000000000..fac8db379118efbd
> > --- /dev/null
> > +++ b/src/lc-compliance/simple_capture.cpp
> > @@ -0,0 +1,149 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright (C) 2020, Google Inc.
> > + *
> > + * simple_capture.cpp - Simple capture helper
> > + */
> > +
> > +#include "simple_capture.h"
> > +
> > +using namespace libcamera;
> > +
> > +SimpleCapture::SimpleCapture(std::shared_ptr<Camera> camera)
> > +	: camera_(camera), allocator_(std::make_unique<FrameBufferAllocator>(camera))
> > +{
> > +}
> > +
> > +SimpleCapture::~SimpleCapture()
> > +{
> > +}
> > +
> > +Results::Result SimpleCapture::configure(StreamRole role)
> > +{
> > +	config_ = camera_->generateConfiguration({ role });
> > +
> > +	if (config_->validate() != CameraConfiguration::Valid) {
> > +		config_.reset();
> > +		return { Results::Fail, "Configuration not valid" };
> > +	}
> > +
> > +	if (camera_->configure(config_.get())) {
> > +		config_.reset();
> > +		return { Results::Fail, "Failed to configure camera" };
> > +	}
> > +
> > +	return { Results::Pass, "Configure camera" };
> > +}
> 
> Is returning a Result here the best option. Shouldn't test results be
> constructed by tests, and helper classes return statuses that let tests
> decide what to do ? In particular, the success message generated by this
> function will never be used, as success applies to a full test, not to
> an invidual step.
> 
> On the other hand, the helper classes have the most detailed knowledge
> about the errors they can encounter. I'm not sure what would be best. I
> wonder if this could be a valid use case for using exceptions. It would
> allow writing tests with assert-like functions. For instance, the code
> below that tests
> 
> 	if (captureCount_ != captureLimit_)
> 		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> 
> could be replaced with a
> 
> 	failIfNotEqual(captureCount_, captureLimit, "request(s)");
> 
> which would generate the message automatically.

I think this is a very interesting idea. And I thought about it when 
writing this but shrugged it off as i thought it would be hard to get 
acceptance upstream. I have not experimented with a prototype for this, 
but maybe this is something we can do on-top as we inclemently improve 
the structure of the tool.

> 
> > +
> > +Results::Result SimpleCapture::start()
> > +{
> > +	Stream *stream = config_->at(0).stream();
> > +	if (allocator_->allocate(stream) < 0)
> > +		return { Results::Fail, "Failed to allocate buffers" };
> > +
> > +	if (camera_->start())
> > +		return { Results::Fail, "Failed to start camera" };
> > +
> > +	camera_->requestCompleted.connect(this, &SimpleCapture::requestComplete);
> > +
> > +	return { Results::Pass, "Started camera" };
> > +}
> > +
> > +Results::Result SimpleCapture::stop()
> > +{
> > +	Stream *stream = config_->at(0).stream();
> > +
> > +	camera_->stop();
> > +
> > +	camera_->requestCompleted.disconnect(this, &SimpleCapture::requestComplete);
> > +
> > +	allocator_->free(stream);
> > +
> > +	return { Results::Pass, "Stopped camera" };
> 
> Generically speaking, should this kind of function be made idempotent,
> and be called from destructors ? It would make error handling easier.

With an exception test flow I think it would make sens.

> 
> > +}
> > +
> > +/* SimpleCaptureBalanced */
> > +
> > +SimpleCaptureBalanced::SimpleCaptureBalanced(std::shared_ptr<Camera> camera)
> > +	: SimpleCapture(camera)
> > +{
> > +}
> > +
> > +Results::Result SimpleCaptureBalanced::capture(unsigned int numRequests)
> > +{
> > +	Results::Result ret = start();
> > +	if (ret.first != Results::Pass)
> > +		return ret;
> > +
> > +	Stream *stream = config_->at(0).stream();
> > +	const std::vector<std::unique_ptr<FrameBuffer>> &buffers = allocator_->buffers(stream);
> > +
> > +	/* No point in testing less requests then the camera depth. */
> > +	if (buffers.size() > numRequests) {
> > +		/* Cache buffers.size() before we destroy it in stop() */
> > +		int buffers_size = buffers.size();
> > +		stop();
> > +
> > +		return { Results::Skip, "Camera needs " + std::to_string(buffers_size)
> > +			+ " requests, can't test only " + std::to_string(numRequests) };
> 
> This makes me wonder what the granularity of a test should be. What is
> "one test", should it be a call to this function with a given number of
> buffers, or one call to testSingleStream() ? I'm leaning towards the
> later, defining a test as something that can be selected in a test plan.
> I can imagine selecting testSingleStream() through a command line
> argument (or through a configuration file), going for a smaller
> granularity doesn't seem too useful. We need to log the status of
> individual steps in a test, but at the top (and TAP) level, I'd limit it
> to the higher level.

I'm heavily biased by my preference for TAP and the test framework 9pm 
(disclaimer partly developed by me) when it comes to how to structure 
tests.

The basic structure is a test case is a collection of TAP test points. 
Each case is specifies the number of test points it has and then in 
order lists if the test point is passed, skipped or failed. The test 
cases is then the worst possible aggregation of all test points. That is 
if one TAP is fail the whole test cases is fail. If one TAP is skip and 
there are no fails the whole case is skip. And only if all TAPs are pass 
is the test case PASS.

This protects against test cases terminating prematurely as the harness 
knows how may TAPs to expect before the actual testing begins.

Then you collect a list of test cases into a test suite and that is your 
top level object.

In this case the testSingleStream is a test case while it could output 
any number of pass/fail/skip TAP points. And the collection of 
testSingleStream, testRequestBalance, testRequestUnbalance would be a 
test suite with 3 test-cases.

But I think the lesson learnt over time is to tailor your test structure 
to the tool/framework you intend to use. For example 9pm would be a 
horrible match for the needs of lc-compliance. I think the best way 
forward for us is to move forward with a our own (does not have to be 
this one) implementation of a test harness and once we know which 
environment it will be used most frequently pick an existing library and 
switch to that.

> 
> > +	}
> > +
> > +	queueCount_ = 0;
> > +	captureCount_ = 0;
> > +	captureLimit_ = numRequests;
> > +
> > +	/* Queue the recommended number of reqeuests. */
> > +	std::vector<std::unique_ptr<libcamera::Request>> requests;
> > +	for (const std::unique_ptr<FrameBuffer> &buffer : buffers) {
> > +		std::unique_ptr<Request> request = camera_->createRequest();
> > +		if (!request) {
> > +			stop();
> > +			return { Results::Fail, "Can't create request" };
> > +		}
> > +
> > +		if (request->addBuffer(stream, buffer.get())) {
> > +			stop();
> > +			return { Results::Fail, "Can't set buffer for request" };
> > +		}
> > +
> > +		if (queueRequest(request.get()) < 0) {
> > +			stop();
> > +			return { Results::Fail, "Failed to queue request" };
> > +		}
> > +
> > +		requests.push_back(std::move(request));
> > +	}
> > +
> > +	/* Run capture session. */
> > +	loop_ = new EventLoop();
> > +	loop_->exec();
> > +	stop();
> > +	delete loop_;
> 
> Should we construct the event loop in the constructor of the base class,
> and delete it in its destructor ?

I thought about that too but ruled again it. Mostly because we had other 
issues with the EventLoop at the time and start/stop it did not really 
work as intended. Maybe we can reopen that when we look at the Exception 
driven testing and keep it simple and readable for now?

> 
> > +
> > +	if (captureCount_ != captureLimit_)
> > +		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> 
> This is a very long line.

I opted to keep string constructing on a single line to ease grepping in 
the code. You are now the n th person commenting about it so I will 
admit defeat and break them :-)

> 
> > +
> > +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests" };
> > +}
> > +
> > +int SimpleCaptureBalanced::queueRequest(Request *request)
> > +{
> > +	queueCount_++;
> > +	if (queueCount_ > captureLimit_)
> > +		return 0;
> > +
> > +	return camera_->queueRequest(request);
> > +}
> > +
> > +void SimpleCaptureBalanced::requestComplete(Request *request)
> > +{
> > +	captureCount_++;
> > +	if (captureCount_ >= captureLimit_) {
> > +		loop_->exit(0);
> > +		return;
> > +	}
> > +
> > +	request->reuse(Request::ReuseBuffers);
> > +	if (queueRequest(request))
> > +		loop_->exit(-EINVAL);
> > +}
> > diff --git a/src/lc-compliance/simple_capture.h b/src/lc-compliance/simple_capture.h
> > new file mode 100644
> > index 0000000000000000..3a6afc538c623050
> > --- /dev/null
> > +++ b/src/lc-compliance/simple_capture.h
> > @@ -0,0 +1,54 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright (C) 2020, Google Inc.
> > + *
> > + * simple_capture.h - Simple capture helper
> > + */
> > +#ifndef __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > +#define __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > +
> > +#include <memory>
> > +
> > +#include <libcamera/libcamera.h>
> > +
> > +#include "../cam/event_loop.h"
> > +#include "results.h"
> > +
> > +class SimpleCapture
> > +{
> > +public:
> > +	Results::Result configure(libcamera::StreamRole role);
> > +
> > +protected:
> > +	SimpleCapture(std::shared_ptr<libcamera::Camera> camera);
> 
> You can pass a libcamera::Camera * as a borrowed reference here, as the
> caller guarantees that the reference stays valid for the lifetime of
> this class.

We could, I opted to use the shared_ptr to keep the use-cases as close 
to what simple applications would use to be able to copy/past code form 
this tool in future when i forgotten the API ;-)

I'm not oppose to changing it but would prefers to keep it the way it 
is.

<snip>

Hi Niklas,

On Mon, Mar 29, 2021 at 06:44:51PM +0200, Niklas Söderlund wrote:
> Hi Laurent,
> 
> Thanks for your feedback.
> 
> On 2021-03-14 22:47:17 +0200, Laurent Pinchart wrote:
> 
> <snip>
> 
> > > diff --git a/src/lc-compliance/simple_capture.cpp 
> > > b/src/lc-compliance/simple_capture.cpp
> > > new file mode 100644
> > > index 0000000000000000..fac8db379118efbd
> > > --- /dev/null
> > > +++ b/src/lc-compliance/simple_capture.cpp
> > > @@ -0,0 +1,149 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > +/*
> > > + * Copyright (C) 2020, Google Inc.
> > > + *
> > > + * simple_capture.cpp - Simple capture helper
> > > + */
> > > +
> > > +#include "simple_capture.h"
> > > +
> > > +using namespace libcamera;
> > > +
> > > +SimpleCapture::SimpleCapture(std::shared_ptr<Camera> camera)
> > > +	: camera_(camera), allocator_(std::make_unique<FrameBufferAllocator>(camera))
> > > +{
> > > +}
> > > +
> > > +SimpleCapture::~SimpleCapture()
> > > +{
> > > +}
> > > +
> > > +Results::Result SimpleCapture::configure(StreamRole role)
> > > +{
> > > +	config_ = camera_->generateConfiguration({ role });
> > > +
> > > +	if (config_->validate() != CameraConfiguration::Valid) {
> > > +		config_.reset();
> > > +		return { Results::Fail, "Configuration not valid" };
> > > +	}
> > > +
> > > +	if (camera_->configure(config_.get())) {
> > > +		config_.reset();
> > > +		return { Results::Fail, "Failed to configure camera" };
> > > +	}
> > > +
> > > +	return { Results::Pass, "Configure camera" };
> > > +}
> > 
> > Is returning a Result here the best option. Shouldn't test results be
> > constructed by tests, and helper classes return statuses that let tests
> > decide what to do ? In particular, the success message generated by this
> > function will never be used, as success applies to a full test, not to
> > an invidual step.
> > 
> > On the other hand, the helper classes have the most detailed knowledge
> > about the errors they can encounter. I'm not sure what would be best. I
> > wonder if this could be a valid use case for using exceptions. It would
> > allow writing tests with assert-like functions. For instance, the code
> > below that tests
> > 
> > 	if (captureCount_ != captureLimit_)
> > 		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > 
> > could be replaced with a
> > 
> > 	failIfNotEqual(captureCount_, captureLimit, "request(s)");
> > 
> > which would generate the message automatically.
> 
> I think this is a very interesting idea. And I thought about it when 
> writing this but shrugged it off as i thought it would be hard to get 
> acceptance upstream. I have not experimented with a prototype for this, 
> but maybe this is something we can do on-top as we inclemently improve 
> the structure of the tool.

https://bugs.libcamera.org/show_bug.cgi?id=17

> > > +
> > > +Results::Result SimpleCapture::start()
> > > +{
> > > +	Stream *stream = config_->at(0).stream();
> > > +	if (allocator_->allocate(stream) < 0)
> > > +		return { Results::Fail, "Failed to allocate buffers" };
> > > +
> > > +	if (camera_->start())
> > > +		return { Results::Fail, "Failed to start camera" };
> > > +
> > > +	camera_->requestCompleted.connect(this, &SimpleCapture::requestComplete);
> > > +
> > > +	return { Results::Pass, "Started camera" };
> > > +}
> > > +
> > > +Results::Result SimpleCapture::stop()
> > > +{
> > > +	Stream *stream = config_->at(0).stream();
> > > +
> > > +	camera_->stop();
> > > +
> > > +	camera_->requestCompleted.disconnect(this, &SimpleCapture::requestComplete);
> > > +
> > > +	allocator_->free(stream);
> > > +
> > > +	return { Results::Pass, "Stopped camera" };
> > 
> > Generically speaking, should this kind of function be made idempotent,
> > and be called from destructors ? It would make error handling easier.
> 
> With an exception test flow I think it would make sens.

https://bugs.libcamera.org/show_bug.cgi?id=18

> > > +}
> > > +
> > > +/* SimpleCaptureBalanced */
> > > +
> > > +SimpleCaptureBalanced::SimpleCaptureBalanced(std::shared_ptr<Camera> camera)
> > > +	: SimpleCapture(camera)
> > > +{
> > > +}
> > > +
> > > +Results::Result SimpleCaptureBalanced::capture(unsigned int numRequests)
> > > +{
> > > +	Results::Result ret = start();
> > > +	if (ret.first != Results::Pass)
> > > +		return ret;
> > > +
> > > +	Stream *stream = config_->at(0).stream();
> > > +	const std::vector<std::unique_ptr<FrameBuffer>> &buffers = allocator_->buffers(stream);
> > > +
> > > +	/* No point in testing less requests then the camera depth. */
> > > +	if (buffers.size() > numRequests) {
> > > +		/* Cache buffers.size() before we destroy it in stop() */
> > > +		int buffers_size = buffers.size();
> > > +		stop();
> > > +
> > > +		return { Results::Skip, "Camera needs " + std::to_string(buffers_size)
> > > +			+ " requests, can't test only " + std::to_string(numRequests) };
> > 
> > This makes me wonder what the granularity of a test should be. What is
> > "one test", should it be a call to this function with a given number of
> > buffers, or one call to testSingleStream() ? I'm leaning towards the
> > later, defining a test as something that can be selected in a test plan.
> > I can imagine selecting testSingleStream() through a command line
> > argument (or through a configuration file), going for a smaller
> > granularity doesn't seem too useful. We need to log the status of
> > individual steps in a test, but at the top (and TAP) level, I'd limit it
> > to the higher level.
> 
> I'm heavily biased by my preference for TAP and the test framework 9pm 
> (disclaimer partly developed by me) when it comes to how to structure 
> tests.
> 
> The basic structure is a test case is a collection of TAP test points. 
> Each case is specifies the number of test points it has and then in 
> order lists if the test point is passed, skipped or failed. The test 
> cases is then the worst possible aggregation of all test points. That is 
> if one TAP is fail the whole test cases is fail. If one TAP is skip and 
> there are no fails the whole case is skip. And only if all TAPs are pass 
> is the test case PASS.
> 
> This protects against test cases terminating prematurely as the harness 
> knows how may TAPs to expect before the actual testing begins.
> 
> Then you collect a list of test cases into a test suite and that is your 
> top level object.

So this means that while test cases can contain multiple test points,
the granularity of selecting what tests to run would be at the test case
level, not the test point level ?

> In this case the testSingleStream is a test case while it could output 
> any number of pass/fail/skip TAP points. And the collection of 
> testSingleStream, testRequestBalance, testRequestUnbalance would be a 
> test suite with 3 test-cases.

You mention that test cases need to report how many test points they
produce. How does this work when a test point failure is fatal and
prevents other test points from running ?

> But I think the lesson learnt over time is to tailor your test structure 
> to the tool/framework you intend to use. For example 9pm would be a 
> horrible match for the needs of lc-compliance. I think the best way 
> forward for us is to move forward with a our own (does not have to be 
> this one) implementation of a test harness and once we know which 
> environment it will be used most frequently pick an existing library and 
> switch to that.
> 
> > > +	}
> > > +
> > > +	queueCount_ = 0;
> > > +	captureCount_ = 0;
> > > +	captureLimit_ = numRequests;
> > > +
> > > +	/* Queue the recommended number of reqeuests. */
> > > +	std::vector<std::unique_ptr<libcamera::Request>> requests;
> > > +	for (const std::unique_ptr<FrameBuffer> &buffer : buffers) {
> > > +		std::unique_ptr<Request> request = camera_->createRequest();
> > > +		if (!request) {
> > > +			stop();
> > > +			return { Results::Fail, "Can't create request" };
> > > +		}
> > > +
> > > +		if (request->addBuffer(stream, buffer.get())) {
> > > +			stop();
> > > +			return { Results::Fail, "Can't set buffer for request" };
> > > +		}
> > > +
> > > +		if (queueRequest(request.get()) < 0) {
> > > +			stop();
> > > +			return { Results::Fail, "Failed to queue request" };
> > > +		}
> > > +
> > > +		requests.push_back(std::move(request));
> > > +	}
> > > +
> > > +	/* Run capture session. */
> > > +	loop_ = new EventLoop();
> > > +	loop_->exec();
> > > +	stop();
> > > +	delete loop_;
> > 
> > Should we construct the event loop in the constructor of the base class,
> > and delete it in its destructor ?
> 
> I thought about that too but ruled again it. Mostly because we had other 
> issues with the EventLoop at the time and start/stop it did not really 
> work as intended. Maybe we can reopen that when we look at the Exception 
> driven testing and keep it simple and readable for now?
> 
> > > +
> > > +	if (captureCount_ != captureLimit_)
> > > +		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > 
> > This is a very long line.
> 
> I opted to keep string constructing on a single line to ease grepping in 
> the code. You are now the n th person commenting about it so I will 
> admit defeat and break them :-)
> 
> > > +
> > > +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests" };
> > > +}
> > > +
> > > +int SimpleCaptureBalanced::queueRequest(Request *request)
> > > +{
> > > +	queueCount_++;
> > > +	if (queueCount_ > captureLimit_)
> > > +		return 0;
> > > +
> > > +	return camera_->queueRequest(request);
> > > +}
> > > +
> > > +void SimpleCaptureBalanced::requestComplete(Request *request)
> > > +{
> > > +	captureCount_++;
> > > +	if (captureCount_ >= captureLimit_) {
> > > +		loop_->exit(0);
> > > +		return;
> > > +	}
> > > +
> > > +	request->reuse(Request::ReuseBuffers);
> > > +	if (queueRequest(request))
> > > +		loop_->exit(-EINVAL);
> > > +}
> > > diff --git a/src/lc-compliance/simple_capture.h b/src/lc-compliance/simple_capture.h
> > > new file mode 100644
> > > index 0000000000000000..3a6afc538c623050
> > > --- /dev/null
> > > +++ b/src/lc-compliance/simple_capture.h
> > > @@ -0,0 +1,54 @@
> > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > +/*
> > > + * Copyright (C) 2020, Google Inc.
> > > + *
> > > + * simple_capture.h - Simple capture helper
> > > + */
> > > +#ifndef __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > +#define __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > +
> > > +#include <memory>
> > > +
> > > +#include <libcamera/libcamera.h>
> > > +
> > > +#include "../cam/event_loop.h"
> > > +#include "results.h"
> > > +
> > > +class SimpleCapture
> > > +{
> > > +public:
> > > +	Results::Result configure(libcamera::StreamRole role);
> > > +
> > > +protected:
> > > +	SimpleCapture(std::shared_ptr<libcamera::Camera> camera);
> > 
> > You can pass a libcamera::Camera * as a borrowed reference here, as the
> > caller guarantees that the reference stays valid for the lifetime of
> > this class.
> 
> We could, I opted to use the shared_ptr to keep the use-cases as close 
> to what simple applications would use to be able to copy/past code form 
> this tool in future when i forgotten the API ;-)

Applications can also use borrowed pointers :-) I think that using a
shared_ptr to model a reference that can be held, and a normal pointer
for a borrowed reference that must not be stored behind the caller's
back may make the code more explicit. There's also a small performance
difference, which doesn't matter here.

At this point I don't think this matters much, we can revisit the code
later.

> I'm not oppose to changing it but would prefers to keep it the way it 
> is.

Hi Niklas,

On Tue, Mar 30, 2021 at 02:31:57AM +0300, Laurent Pinchart wrote:
> On Mon, Mar 29, 2021 at 06:44:51PM +0200, Niklas Söderlund wrote:
> > On 2021-03-14 22:47:17 +0200, Laurent Pinchart wrote:
> > 
> > <snip>
> > 
> > > > diff --git a/src/lc-compliance/simple_capture.cpp 
> > > > b/src/lc-compliance/simple_capture.cpp
> > > > new file mode 100644
> > > > index 0000000000000000..fac8db379118efbd
> > > > --- /dev/null
> > > > +++ b/src/lc-compliance/simple_capture.cpp
> > > > @@ -0,0 +1,149 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > > +/*
> > > > + * Copyright (C) 2020, Google Inc.
> > > > + *
> > > > + * simple_capture.cpp - Simple capture helper
> > > > + */
> > > > +
> > > > +#include "simple_capture.h"
> > > > +
> > > > +using namespace libcamera;
> > > > +
> > > > +SimpleCapture::SimpleCapture(std::shared_ptr<Camera> camera)
> > > > +	: camera_(camera), allocator_(std::make_unique<FrameBufferAllocator>(camera))
> > > > +{
> > > > +}
> > > > +
> > > > +SimpleCapture::~SimpleCapture()
> > > > +{
> > > > +}
> > > > +
> > > > +Results::Result SimpleCapture::configure(StreamRole role)
> > > > +{
> > > > +	config_ = camera_->generateConfiguration({ role });
> > > > +
> > > > +	if (config_->validate() != CameraConfiguration::Valid) {
> > > > +		config_.reset();
> > > > +		return { Results::Fail, "Configuration not valid" };
> > > > +	}
> > > > +
> > > > +	if (camera_->configure(config_.get())) {
> > > > +		config_.reset();
> > > > +		return { Results::Fail, "Failed to configure camera" };
> > > > +	}
> > > > +
> > > > +	return { Results::Pass, "Configure camera" };
> > > > +}
> > > 
> > > Is returning a Result here the best option. Shouldn't test results be
> > > constructed by tests, and helper classes return statuses that let tests
> > > decide what to do ? In particular, the success message generated by this
> > > function will never be used, as success applies to a full test, not to
> > > an invidual step.
> > > 
> > > On the other hand, the helper classes have the most detailed knowledge
> > > about the errors they can encounter. I'm not sure what would be best. I
> > > wonder if this could be a valid use case for using exceptions. It would
> > > allow writing tests with assert-like functions. For instance, the code
> > > below that tests
> > > 
> > > 	if (captureCount_ != captureLimit_)
> > > 		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > > 
> > > could be replaced with a
> > > 
> > > 	failIfNotEqual(captureCount_, captureLimit, "request(s)");
> > > 
> > > which would generate the message automatically.
> > 
> > I think this is a very interesting idea. And I thought about it when 
> > writing this but shrugged it off as i thought it would be hard to get 
> > acceptance upstream. I have not experimented with a prototype for this, 
> > but maybe this is something we can do on-top as we inclemently improve 
> > the structure of the tool.
> 
> https://bugs.libcamera.org/show_bug.cgi?id=17
> 
> > > > +
> > > > +Results::Result SimpleCapture::start()
> > > > +{
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +	if (allocator_->allocate(stream) < 0)
> > > > +		return { Results::Fail, "Failed to allocate buffers" };
> > > > +
> > > > +	if (camera_->start())
> > > > +		return { Results::Fail, "Failed to start camera" };
> > > > +
> > > > +	camera_->requestCompleted.connect(this, &SimpleCapture::requestComplete);
> > > > +
> > > > +	return { Results::Pass, "Started camera" };
> > > > +}
> > > > +
> > > > +Results::Result SimpleCapture::stop()
> > > > +{
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +
> > > > +	camera_->stop();
> > > > +
> > > > +	camera_->requestCompleted.disconnect(this, &SimpleCapture::requestComplete);
> > > > +
> > > > +	allocator_->free(stream);
> > > > +
> > > > +	return { Results::Pass, "Stopped camera" };
> > > 
> > > Generically speaking, should this kind of function be made idempotent,
> > > and be called from destructors ? It would make error handling easier.
> > 
> > With an exception test flow I think it would make sens.
> 
> https://bugs.libcamera.org/show_bug.cgi?id=18
> 
> > > > +}
> > > > +
> > > > +/* SimpleCaptureBalanced */
> > > > +
> > > > +SimpleCaptureBalanced::SimpleCaptureBalanced(std::shared_ptr<Camera> camera)
> > > > +	: SimpleCapture(camera)
> > > > +{
> > > > +}
> > > > +
> > > > +Results::Result SimpleCaptureBalanced::capture(unsigned int numRequests)
> > > > +{
> > > > +	Results::Result ret = start();
> > > > +	if (ret.first != Results::Pass)
> > > > +		return ret;
> > > > +
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +	const std::vector<std::unique_ptr<FrameBuffer>> &buffers = allocator_->buffers(stream);
> > > > +
> > > > +	/* No point in testing less requests then the camera depth. */
> > > > +	if (buffers.size() > numRequests) {
> > > > +		/* Cache buffers.size() before we destroy it in stop() */
> > > > +		int buffers_size = buffers.size();
> > > > +		stop();
> > > > +
> > > > +		return { Results::Skip, "Camera needs " + std::to_string(buffers_size)
> > > > +			+ " requests, can't test only " + std::to_string(numRequests) };
> > > 
> > > This makes me wonder what the granularity of a test should be. What is
> > > "one test", should it be a call to this function with a given number of
> > > buffers, or one call to testSingleStream() ? I'm leaning towards the
> > > later, defining a test as something that can be selected in a test plan.
> > > I can imagine selecting testSingleStream() through a command line
> > > argument (or through a configuration file), going for a smaller
> > > granularity doesn't seem too useful. We need to log the status of
> > > individual steps in a test, but at the top (and TAP) level, I'd limit it
> > > to the higher level.
> > 
> > I'm heavily biased by my preference for TAP and the test framework 9pm 
> > (disclaimer partly developed by me) when it comes to how to structure 
> > tests.
> > 
> > The basic structure is a test case is a collection of TAP test points. 
> > Each case is specifies the number of test points it has and then in 
> > order lists if the test point is passed, skipped or failed. The test 
> > cases is then the worst possible aggregation of all test points. That is 
> > if one TAP is fail the whole test cases is fail. If one TAP is skip and 
> > there are no fails the whole case is skip. And only if all TAPs are pass 
> > is the test case PASS.
> > 
> > This protects against test cases terminating prematurely as the harness 
> > knows how may TAPs to expect before the actual testing begins.
> > 
> > Then you collect a list of test cases into a test suite and that is your 
> > top level object.
> 
> So this means that while test cases can contain multiple test points,
> the granularity of selecting what tests to run would be at the test case
> level, not the test point level ?
> 
> > In this case the testSingleStream is a test case while it could output 
> > any number of pass/fail/skip TAP points. And the collection of 
> > testSingleStream, testRequestBalance, testRequestUnbalance would be a 
> > test suite with 3 test-cases.
> 
> You mention that test cases need to report how many test points they
> produce. How does this work when a test point failure is fatal and
> prevents other test points from running ?

https://bugs.libcamera.org/show_bug.cgi?id=19

> > But I think the lesson learnt over time is to tailor your test structure 
> > to the tool/framework you intend to use. For example 9pm would be a 
> > horrible match for the needs of lc-compliance. I think the best way 
> > forward for us is to move forward with a our own (does not have to be 
> > this one) implementation of a test harness and once we know which 
> > environment it will be used most frequently pick an existing library and 
> > switch to that.
> > 
> > > > +	}
> > > > +
> > > > +	queueCount_ = 0;
> > > > +	captureCount_ = 0;
> > > > +	captureLimit_ = numRequests;
> > > > +
> > > > +	/* Queue the recommended number of reqeuests. */
> > > > +	std::vector<std::unique_ptr<libcamera::Request>> requests;
> > > > +	for (const std::unique_ptr<FrameBuffer> &buffer : buffers) {
> > > > +		std::unique_ptr<Request> request = camera_->createRequest();
> > > > +		if (!request) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Can't create request" };
> > > > +		}
> > > > +
> > > > +		if (request->addBuffer(stream, buffer.get())) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Can't set buffer for request" };
> > > > +		}
> > > > +
> > > > +		if (queueRequest(request.get()) < 0) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Failed to queue request" };
> > > > +		}
> > > > +
> > > > +		requests.push_back(std::move(request));
> > > > +	}
> > > > +
> > > > +	/* Run capture session. */
> > > > +	loop_ = new EventLoop();
> > > > +	loop_->exec();
> > > > +	stop();
> > > > +	delete loop_;
> > > 
> > > Should we construct the event loop in the constructor of the base class,
> > > and delete it in its destructor ?
> > 
> > I thought about that too but ruled again it. Mostly because we had other 
> > issues with the EventLoop at the time and start/stop it did not really 
> > work as intended. Maybe we can reopen that when we look at the Exception 
> > driven testing and keep it simple and readable for now?
> > 
> > > > +
> > > > +	if (captureCount_ != captureLimit_)
> > > > +		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > > 
> > > This is a very long line.
> > 
> > I opted to keep string constructing on a single line to ease grepping in 
> > the code. You are now the n th person commenting about it so I will 
> > admit defeat and break them :-)
> > 
> > > > +
> > > > +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests" };
> > > > +}
> > > > +
> > > > +int SimpleCaptureBalanced::queueRequest(Request *request)
> > > > +{
> > > > +	queueCount_++;
> > > > +	if (queueCount_ > captureLimit_)
> > > > +		return 0;
> > > > +
> > > > +	return camera_->queueRequest(request);
> > > > +}
> > > > +
> > > > +void SimpleCaptureBalanced::requestComplete(Request *request)
> > > > +{
> > > > +	captureCount_++;
> > > > +	if (captureCount_ >= captureLimit_) {
> > > > +		loop_->exit(0);
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	request->reuse(Request::ReuseBuffers);
> > > > +	if (queueRequest(request))
> > > > +		loop_->exit(-EINVAL);
> > > > +}
> > > > diff --git a/src/lc-compliance/simple_capture.h b/src/lc-compliance/simple_capture.h
> > > > new file mode 100644
> > > > index 0000000000000000..3a6afc538c623050
> > > > --- /dev/null
> > > > +++ b/src/lc-compliance/simple_capture.h
> > > > @@ -0,0 +1,54 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > > +/*
> > > > + * Copyright (C) 2020, Google Inc.
> > > > + *
> > > > + * simple_capture.h - Simple capture helper
> > > > + */
> > > > +#ifndef __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > > +#define __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > > +
> > > > +#include <memory>
> > > > +
> > > > +#include <libcamera/libcamera.h>
> > > > +
> > > > +#include "../cam/event_loop.h"
> > > > +#include "results.h"
> > > > +
> > > > +class SimpleCapture
> > > > +{
> > > > +public:
> > > > +	Results::Result configure(libcamera::StreamRole role);
> > > > +
> > > > +protected:
> > > > +	SimpleCapture(std::shared_ptr<libcamera::Camera> camera);
> > > 
> > > You can pass a libcamera::Camera * as a borrowed reference here, as the
> > > caller guarantees that the reference stays valid for the lifetime of
> > > this class.
> > 
> > We could, I opted to use the shared_ptr to keep the use-cases as close 
> > to what simple applications would use to be able to copy/past code form 
> > this tool in future when i forgotten the API ;-)
> 
> Applications can also use borrowed pointers :-) I think that using a
> shared_ptr to model a reference that can be held, and a normal pointer
> for a borrowed reference that must not be stored behind the caller's
> back may make the code more explicit. There's also a small performance
> difference, which doesn't matter here.
> 
> At this point I don't think this matters much, we can revisit the code
> later.
> 
> > I'm not oppose to changing it but would prefers to keep it the way it 
> > is.

Hi Laurent,

On 2021-03-30 02:31:54 +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> On Mon, Mar 29, 2021 at 06:44:51PM +0200, Niklas Söderlund wrote:
> > Hi Laurent,
> > 
> > Thanks for your feedback.
> > 
> > On 2021-03-14 22:47:17 +0200, Laurent Pinchart wrote:
> > 
> > <snip>
> > 
> > > > diff --git a/src/lc-compliance/simple_capture.cpp 
> > > > b/src/lc-compliance/simple_capture.cpp
> > > > new file mode 100644
> > > > index 0000000000000000..fac8db379118efbd
> > > > --- /dev/null
> > > > +++ b/src/lc-compliance/simple_capture.cpp
> > > > @@ -0,0 +1,149 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > > +/*
> > > > + * Copyright (C) 2020, Google Inc.
> > > > + *
> > > > + * simple_capture.cpp - Simple capture helper
> > > > + */
> > > > +
> > > > +#include "simple_capture.h"
> > > > +
> > > > +using namespace libcamera;
> > > > +
> > > > +SimpleCapture::SimpleCapture(std::shared_ptr<Camera> camera)
> > > > +	: camera_(camera), allocator_(std::make_unique<FrameBufferAllocator>(camera))
> > > > +{
> > > > +}
> > > > +
> > > > +SimpleCapture::~SimpleCapture()
> > > > +{
> > > > +}
> > > > +
> > > > +Results::Result SimpleCapture::configure(StreamRole role)
> > > > +{
> > > > +	config_ = camera_->generateConfiguration({ role });
> > > > +
> > > > +	if (config_->validate() != CameraConfiguration::Valid) {
> > > > +		config_.reset();
> > > > +		return { Results::Fail, "Configuration not valid" };
> > > > +	}
> > > > +
> > > > +	if (camera_->configure(config_.get())) {
> > > > +		config_.reset();
> > > > +		return { Results::Fail, "Failed to configure camera" };
> > > > +	}
> > > > +
> > > > +	return { Results::Pass, "Configure camera" };
> > > > +}
> > > 
> > > Is returning a Result here the best option. Shouldn't test results be
> > > constructed by tests, and helper classes return statuses that let tests
> > > decide what to do ? In particular, the success message generated by this
> > > function will never be used, as success applies to a full test, not to
> > > an invidual step.
> > > 
> > > On the other hand, the helper classes have the most detailed knowledge
> > > about the errors they can encounter. I'm not sure what would be best. I
> > > wonder if this could be a valid use case for using exceptions. It would
> > > allow writing tests with assert-like functions. For instance, the code
> > > below that tests
> > > 
> > > 	if (captureCount_ != captureLimit_)
> > > 		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > > 
> > > could be replaced with a
> > > 
> > > 	failIfNotEqual(captureCount_, captureLimit, "request(s)");
> > > 
> > > which would generate the message automatically.
> > 
> > I think this is a very interesting idea. And I thought about it when 
> > writing this but shrugged it off as i thought it would be hard to get 
> > acceptance upstream. I have not experimented with a prototype for this, 
> > but maybe this is something we can do on-top as we inclemently improve 
> > the structure of the tool.
> 
> https://bugs.libcamera.org/show_bug.cgi?id=17
> 
> > > > +
> > > > +Results::Result SimpleCapture::start()
> > > > +{
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +	if (allocator_->allocate(stream) < 0)
> > > > +		return { Results::Fail, "Failed to allocate buffers" };
> > > > +
> > > > +	if (camera_->start())
> > > > +		return { Results::Fail, "Failed to start camera" };
> > > > +
> > > > +	camera_->requestCompleted.connect(this, &SimpleCapture::requestComplete);
> > > > +
> > > > +	return { Results::Pass, "Started camera" };
> > > > +}
> > > > +
> > > > +Results::Result SimpleCapture::stop()
> > > > +{
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +
> > > > +	camera_->stop();
> > > > +
> > > > +	camera_->requestCompleted.disconnect(this, &SimpleCapture::requestComplete);
> > > > +
> > > > +	allocator_->free(stream);
> > > > +
> > > > +	return { Results::Pass, "Stopped camera" };
> > > 
> > > Generically speaking, should this kind of function be made idempotent,
> > > and be called from destructors ? It would make error handling easier.
> > 
> > With an exception test flow I think it would make sens.
> 
> https://bugs.libcamera.org/show_bug.cgi?id=18
> 
> > > > +}
> > > > +
> > > > +/* SimpleCaptureBalanced */
> > > > +
> > > > +SimpleCaptureBalanced::SimpleCaptureBalanced(std::shared_ptr<Camera> camera)
> > > > +	: SimpleCapture(camera)
> > > > +{
> > > > +}
> > > > +
> > > > +Results::Result SimpleCaptureBalanced::capture(unsigned int numRequests)
> > > > +{
> > > > +	Results::Result ret = start();
> > > > +	if (ret.first != Results::Pass)
> > > > +		return ret;
> > > > +
> > > > +	Stream *stream = config_->at(0).stream();
> > > > +	const std::vector<std::unique_ptr<FrameBuffer>> &buffers = allocator_->buffers(stream);
> > > > +
> > > > +	/* No point in testing less requests then the camera depth. */
> > > > +	if (buffers.size() > numRequests) {
> > > > +		/* Cache buffers.size() before we destroy it in stop() */
> > > > +		int buffers_size = buffers.size();
> > > > +		stop();
> > > > +
> > > > +		return { Results::Skip, "Camera needs " + std::to_string(buffers_size)
> > > > +			+ " requests, can't test only " + std::to_string(numRequests) };
> > > 
> > > This makes me wonder what the granularity of a test should be. What is
> > > "one test", should it be a call to this function with a given number of
> > > buffers, or one call to testSingleStream() ? I'm leaning towards the
> > > later, defining a test as something that can be selected in a test plan.
> > > I can imagine selecting testSingleStream() through a command line
> > > argument (or through a configuration file), going for a smaller
> > > granularity doesn't seem too useful. We need to log the status of
> > > individual steps in a test, but at the top (and TAP) level, I'd limit it
> > > to the higher level.
> > 
> > I'm heavily biased by my preference for TAP and the test framework 9pm 
> > (disclaimer partly developed by me) when it comes to how to structure 
> > tests.
> > 
> > The basic structure is a test case is a collection of TAP test points. 
> > Each case is specifies the number of test points it has and then in 
> > order lists if the test point is passed, skipped or failed. The test 
> > cases is then the worst possible aggregation of all test points. That is 
> > if one TAP is fail the whole test cases is fail. If one TAP is skip and 
> > there are no fails the whole case is skip. And only if all TAPs are pass 
> > is the test case PASS.
> > 
> > This protects against test cases terminating prematurely as the harness 
> > knows how may TAPs to expect before the actual testing begins.
> > 
> > Then you collect a list of test cases into a test suite and that is your 
> > top level object.
> 
> So this means that while test cases can contain multiple test points,
> the granularity of selecting what tests to run would be at the test case
> level, not the test point level ?

Yes.

> 
> > In this case the testSingleStream is a test case while it could output 
> > any number of pass/fail/skip TAP points. And the collection of 
> > testSingleStream, testRequestBalance, testRequestUnbalance would be a 
> > test suite with 3 test-cases.
> 
> You mention that test cases need to report how many test points they
> produce. How does this work when a test point failure is fatal and
> prevents other test points from running ?

Any test case that produces less then (or more then) the number of TAP 
test points then it reported in its test plan is a failed test. This is 
one feature of TAP I really like as it acts as a sanity check on the 
test itself. Naturally if we go with a different test framework this may 
need to be reconsider if the concept of plans do not exist.

Side note, I'm happy that you caught this special case of test cases as 
'fatal fail' was a feature we took quiet seriously in 9pm and really got 
right in the API using the 'fun' upvar and uplevel constructs of TCL :-)

https://github.com/rical/9pm/blob/master/output.tcl#L211

> 
> > But I think the lesson learnt over time is to tailor your test structure 
> > to the tool/framework you intend to use. For example 9pm would be a 
> > horrible match for the needs of lc-compliance. I think the best way 
> > forward for us is to move forward with a our own (does not have to be 
> > this one) implementation of a test harness and once we know which 
> > environment it will be used most frequently pick an existing library and 
> > switch to that.
> > 
> > > > +	}
> > > > +
> > > > +	queueCount_ = 0;
> > > > +	captureCount_ = 0;
> > > > +	captureLimit_ = numRequests;
> > > > +
> > > > +	/* Queue the recommended number of reqeuests. */
> > > > +	std::vector<std::unique_ptr<libcamera::Request>> requests;
> > > > +	for (const std::unique_ptr<FrameBuffer> &buffer : buffers) {
> > > > +		std::unique_ptr<Request> request = camera_->createRequest();
> > > > +		if (!request) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Can't create request" };
> > > > +		}
> > > > +
> > > > +		if (request->addBuffer(stream, buffer.get())) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Can't set buffer for request" };
> > > > +		}
> > > > +
> > > > +		if (queueRequest(request.get()) < 0) {
> > > > +			stop();
> > > > +			return { Results::Fail, "Failed to queue request" };
> > > > +		}
> > > > +
> > > > +		requests.push_back(std::move(request));
> > > > +	}
> > > > +
> > > > +	/* Run capture session. */
> > > > +	loop_ = new EventLoop();
> > > > +	loop_->exec();
> > > > +	stop();
> > > > +	delete loop_;
> > > 
> > > Should we construct the event loop in the constructor of the base class,
> > > and delete it in its destructor ?
> > 
> > I thought about that too but ruled again it. Mostly because we had other 
> > issues with the EventLoop at the time and start/stop it did not really 
> > work as intended. Maybe we can reopen that when we look at the Exception 
> > driven testing and keep it simple and readable for now?
> > 
> > > > +
> > > > +	if (captureCount_ != captureLimit_)
> > > > +		return { Results::Fail, "Got " + std::to_string(captureCount_) + " request, wanted " + std::to_string(captureLimit_) };
> > > 
> > > This is a very long line.
> > 
> > I opted to keep string constructing on a single line to ease grepping in 
> > the code. You are now the n th person commenting about it so I will 
> > admit defeat and break them :-)
> > 
> > > > +
> > > > +	return { Results::Pass, "Balanced capture of " + std::to_string(numRequests) + " requests" };
> > > > +}
> > > > +
> > > > +int SimpleCaptureBalanced::queueRequest(Request *request)
> > > > +{
> > > > +	queueCount_++;
> > > > +	if (queueCount_ > captureLimit_)
> > > > +		return 0;
> > > > +
> > > > +	return camera_->queueRequest(request);
> > > > +}
> > > > +
> > > > +void SimpleCaptureBalanced::requestComplete(Request *request)
> > > > +{
> > > > +	captureCount_++;
> > > > +	if (captureCount_ >= captureLimit_) {
> > > > +		loop_->exit(0);
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	request->reuse(Request::ReuseBuffers);
> > > > +	if (queueRequest(request))
> > > > +		loop_->exit(-EINVAL);
> > > > +}
> > > > diff --git a/src/lc-compliance/simple_capture.h b/src/lc-compliance/simple_capture.h
> > > > new file mode 100644
> > > > index 0000000000000000..3a6afc538c623050
> > > > --- /dev/null
> > > > +++ b/src/lc-compliance/simple_capture.h
> > > > @@ -0,0 +1,54 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > > > +/*
> > > > + * Copyright (C) 2020, Google Inc.
> > > > + *
> > > > + * simple_capture.h - Simple capture helper
> > > > + */
> > > > +#ifndef __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > > +#define __LC_COMPLIANCE_SIMPLE_CAPTURE_H__
> > > > +
> > > > +#include <memory>
> > > > +
> > > > +#include <libcamera/libcamera.h>
> > > > +
> > > > +#include "../cam/event_loop.h"
> > > > +#include "results.h"
> > > > +
> > > > +class SimpleCapture
> > > > +{
> > > > +public:
> > > > +	Results::Result configure(libcamera::StreamRole role);
> > > > +
> > > > +protected:
> > > > +	SimpleCapture(std::shared_ptr<libcamera::Camera> camera);
> > > 
> > > You can pass a libcamera::Camera * as a borrowed reference here, as the
> > > caller guarantees that the reference stays valid for the lifetime of
> > > this class.
> > 
> > We could, I opted to use the shared_ptr to keep the use-cases as close 
> > to what simple applications would use to be able to copy/past code form 
> > this tool in future when i forgotten the API ;-)
> 
> Applications can also use borrowed pointers :-) I think that using a
> shared_ptr to model a reference that can be held, and a normal pointer
> for a borrowed reference that must not be stored behind the caller's
> back may make the code more explicit. There's also a small performance
> difference, which doesn't matter here.
> 
> At this point I don't think this matters much, we can revisit the code
> later.
> 
> > I'm not oppose to changing it but would prefers to keep it the way it 
> > is.
> 
> -- 
> Regards,
> 
> Laurent Pinchart