summaryrefslogtreecommitdiff
path: root/test/media_device/media_device_print_test.cpp
diff options
context:
space:
mode:
authorNaushir Patuck <naush@raspberrypi.com>2022-07-18 09:15:59 +0100
committerLaurent Pinchart <laurent.pinchart@ideasonboard.com>2022-07-28 13:47:51 +0300
commit2ef6eafb6f4efc8a9ae7381253c7121d488d123d (patch)
treec2ef147494201d2689a63dcbfa293e2ab0ee5c05 /test/media_device/media_device_print_test.cpp
parentc1597f989654618f782012104f547b367082fa3e (diff)
ipa: raspberrypi: Introduce version 2.0 format for the camera tuning file
The existing tuning file format (version 1.0) requires the controller algorithms to run in the same order as listed in the JSON structure. The JSON specification does not mandate any such ordering, but the Boost JSON parser would maintain this order. In order to remove this reliance on the parser to provide ordering, introduce a new version 2.0 format for the camera tuning file. In this version, the algorithms are specified in a top level list node ("algorithms"), which does require strict ordering of the elements. A "version" node is added to distinguish between the version 1.0 and 2.0 formats. The absence of the "version" node implies version 1.0. A "target" node is also added to specify the target platform for this configuration. Update the controller to support either version of the tuning file by looking at the version node. CreateAlgorithm member function to now load and configure each algorithm. Additionally, make CreateAlgorithm a private member, it does not get called externally. If a version 1.0 format tuning file is used, throw a warning message indicating it will be soon deprecated. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Diffstat (limited to 'test/media_device/media_device_print_test.cpp')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.1 (git 2.18.0) at 2025-01-05 18:40:38 +0000
lass="hl kwc">public Object { public: TimeoutHandler() : timer_(this), timeout_(false) { timer_.timeout.connect(this, &TimeoutHandler::timeoutHandler); } void start() { timer_.start(100ms); } bool timeout() const { return timeout_; } private: void timeoutHandler() { timeout_ = true; } Timer timer_; bool timeout_; }; class TimerFailTest : public Test { protected: int init() { thread_.start(); timeout_ = new TimeoutHandler(); timeout_->moveToThread(&thread_); return TestPass; } int run() { /* * Test that the forbidden operation of starting the timer from * another thread results in a failure. We need to interrupt the * event dispatcher to make sure we don't succeed simply because * the event dispatcher hasn't noticed the timer restart. */ timeout_->start(); thread_.eventDispatcher()->interrupt(); this_thread::sleep_for(chrono::milliseconds(200)); /* * The wrong start() call should result in an assertion in debug * builds, and a timeout in release builds. The test is * therefore marked in meson.build as expected to fail. We need * to return TestPass in the unexpected (usually known as * "fail") case, and TestFail otherwise. */ if (timeout_->timeout()) { cout << "Timer start from wrong thread succeeded unexpectedly" << endl; return TestPass; } return TestFail; } void cleanup() { /* * Object class instances must be destroyed from the thread * they live in. */ timeout_->deleteLater(); thread_.exit(0); thread_.wait(); } private: TimeoutHandler *timeout_; Thread thread_; }; TEST_REGISTER(TimerFailTest)
generated by cgit v1.2.1 (git 2.18.0) at 2025-01-05 18:40:38 +0000