| Age | Commit message (Collapse) | Author |
|---|
|
The Extensible and Extensible::Private classes contain pointers to each
other. These pointers are initialized in the respective class's
constructor, by passing a pointer to the other class to each
constructor. This particular construct reduces the flexibility of the
Extensible pattern, as the Private class instance has to be allocated
and constructed in the members initializer list of the Extensible
class's constructor. It is thus impossible to perform any operation on
the Private class between its construction and the construction of the
Extensible class, or to subclass the Private class without subclassing
the Extensible class.
To make the design pattern more flexible, don't pass the pointer to the
Extensible class to the Private class's constructor, but initialize the
pointer manually in the Extensible class's constructor. This requires a
const_cast as the o_ member of the Private class is const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The Extensible::_d() functions are meant to be called by users of the
class. Document them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add type safety by turning the MapFlag and OpenModeFlag enum into enum
class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced Flags<> class to store a bitfield of
File::OpenMode in a type-safe way. The existing File::OpenMode enum is
renamed to File::OpenModeFlag to free the File::OpenMode for the Flags<>
type alias.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use the newly introduced Flags<> class to store a bitfield of
File::MapFlag in a type-safe way.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a Flags template class that provide type-safe bitwise operators on
enum values. This allows using enum types for bit fields, without giving
away type-safety as usually done when storing combined flags in integer
variables.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Now that all Extensible classes expose a _d() function that performs
appropriate casts, the LIBCAMERA_D_PTR brings no real additional value.
Replace it with direct calls to the _d() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Despite sharing the same name, the private data class created by the
Extensible design pattern and the C++ private access specifier have
different goals. The latter specifies class members private to the
class, while the former stores data not visible to the application.
There are use cases for accessing the private data class from other
classes inside libcamera. Make this possible by exposing public _d()
functions in the class deriving from Extensible. This won't allow access
to the private data by applications as the definition of the Private
class isn't visible outside of libcamera.
The _d() functions need to be defined as template functions to delay
their evaluation, as the static_cast() operator in the Extensible::_d()
functions needs the Private class to be fully defined. The template
argument is defaulted and ignored, as only its presence is required to
delay evaluation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The utils::hex() function is defined as a function template that has
implementations for integer arguments only. When given a different
argument type, the compiler will not catch the issue, but linking will
fail:
src/libcamera/libcamera.so.p/camera_sensor.cpp.o: in function `libcamera::CameraSensor::validateSensorDriver()':
camera_sensor.cpp:(.text+0x1e6b): undefined reference to `libcamera::utils::_hex libcamera::utils::hex<libcamera::ControlId const*>(libcamera::ControlId const*, unsigned int)'
Move the failure to compilation time by enabling the function for
integer arguments only. This provides better diagnostics:
../../src/libcamera/camera_sensor.cpp: In member function ‘int libcamera::CameraSensor::validateSensorDriver()’:
../../src/libcamera/camera_sensor.cpp:199:77: error: no matching function for call to ‘hex(const libcamera::ControlId*&)’
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Headers which must not be exposed as part of the public libcamera API
should include base/private.h.
Any interface which includes the private.h header will only be able to
build if the libcamera_private dependency is used (or the
libcamera_base_private dependency directly).
Build targets which are intended to use the private API's will use the
libcamera_private to handle the automatic definition of the inclusion
guard.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move span, and adjust the Doxygen exclusion as well.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the event notifier, and associated header updates.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The File abstraction is a base helper and not part of the libcamera
API. Move it to to allow usage by users of the base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the class support infrastructure to the base library.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the utils functionality to the libcamera/base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera-base.so will feature internal support functionality
that is utilised by libcamera, and can be shared in other places.
This new library provides a layer beneath libcamera which provides
common abstractions to internal objects.
A pkg-config file is generated and named libcamera-base.pc which allows
components such as external IPA modules to link directly to this library
if they need. Normal applications will reference this library through
the Requires: statement provided by the libcamera.pc package
configuration, and linkage will be handled automatically through the
pkg-config mechanisms.
No code is moved to this library yet, this patch only introduces the
framework, construction and linkage.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
