| Age | Commit message (Collapse) | Author |
|---|
|
Buffer instances reference memory, which is modelled internally by a
BufferMemory instance. Store a pointer to the BufferMemory in the Buffer
class, and populate it when the buffer is queued to the camera through a
request. This is useful for applications to access the buffer memory in
the buffer or request completion handler.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
All interactions with the Stream's buffers currently go through the
BufferPool. In order to shorten accessing the buffers array, and eventually
restrict access to the Stream's internal buffer pool, provide operations to
access, create and destroy buffers.
It is still possible to access the pool for pipeline handlers to
populate it by exporting buffers from a video device to Stream's pool.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The cam and qcam applications, as well as the camera capture test case,
access the Stream::bufferPool in order to know how many requests to
initially queue. As part of an effort to remove access to the buffer
pool from applications, use the buffer count from the stream
configuration instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The Buffer class is a large beast the stores information about the
buffer memory, dynamic metadata related to the frame stored in the
buffer, and buffer reference data (in the index). In order to implement
buffer import we will need to extend this with dmabuf file descriptors,
making usage of the class even more complex.
Refactor the Buffer class by splitting the buffer memory information to
a BufferMemory class, and repurposing the Buffer class to reference a
buffer and to store dynamic metadata. The BufferMemory class becomes a
long term storage, valid and stable from the time buffer memory is
allocated to the time it is freed. The Buffer class, on the other hand,
becomes transient, is created on demand when an application requires a
buffer, is given to a request, and is deleted when the request
completes.
Buffer and BufferMemory don't need to be copied, so their copy
constructor and assignment operators are deleted.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
queueRequest() is called after starting the stream.
If it fails, the stream should be stopped, otherwise it can get a
"Device or resource busy" error, due to VIDIOC_REQBUFS ioctls being
called after VIDIOC_STREAMON without VIDIOC_STREAMOFF in-between.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Most of the camera configuration preparation that is done in the
Capture module is not specific to capturing and could be useful for
other modules. Extract the generic parts to CamApp and do basic
preparation of the configuration before passing it to modules.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Reduce the complexity of main.cpp by compartmentalising the capture
logic into its own class. There is no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
