libcamera  v0.1.0+127-8e215127
Supporting cameras in Linux since 2019
Classes | Public Member Functions | List of all members
libcamera::DelayedControls Class Reference

Helper to deal with controls that take effect with a delay. More...


struct  ControlParams
 Parameters associated with controls handled by the DelayedControls helper class. More...

Public Member Functions

 DelayedControls (V4L2Device *device, const std::unordered_map< uint32_t, ControlParams > &controlParams)
 Construct a DelayedControls instance. More...
void reset ()
 Reset state machine. More...
bool push (const ControlList &controls)
 Push a set of controls on the queue. More...
ControlList get (uint32_t sequence)
 Read back controls in effect at a sequence number. More...
void applyControls (uint32_t sequence)
 Inform DelayedControls of the start of a new frame. More...

Detailed Description

Helper to deal with controls that take effect with a delay.

Some sensor controls take effect with a delay as the sensor needs time to adjust, for example exposure and analog gain. This is a helper class to deal with such controls and the intended users are pipeline handlers.

The idea is to extend the concept of the buffer depth of a pipeline the application needs to maintain to also cover controls. Just as with buffer depth if the application keeps the number of requests queued above the control depth the controls are guaranteed to take effect for the correct request. The control depth is determined by the control with the greatest delay.

Constructor & Destructor Documentation

◆ DelayedControls()

libcamera::DelayedControls::DelayedControls ( V4L2Device device,
const std::unordered_map< uint32_t, ControlParams > &  controlParams 

Construct a DelayedControls instance.

[in]deviceThe V4L2 device the controls have to be applied to
[in]controlParamsMap of the numerical V4L2 control ids to their associated control parameters.

The control parameters comprise of delays (in frames) and a priority write flag. If this flag is set, the relevant control is written separately from, and ahead of the rest of the batched controls.

Only controls specified in controlParams are handled. If it's desired to mix delayed controls and controls that take effect immediately the immediate controls must be listed in the controlParams map with a delay value of 0.

Member Function Documentation

◆ applyControls()

void libcamera::DelayedControls::applyControls ( uint32_t  sequence)

Inform DelayedControls of the start of a new frame.

[in]sequenceSequence number of the frame that started

Inform the state machine that a new frame has started and of its sequence number. Any user of these helpers is responsible to inform the helper about the start of any frame. This can be connected with ease to the start of a exposure (SOE) V4L2 event.

◆ get()

ControlList libcamera::DelayedControls::get ( uint32_t  sequence)

Read back controls in effect at a sequence number.

[in]sequenceThe sequence number to get controls for

Read back what controls where in effect at a specific sequence number. The history is a ring buffer of 16 entries where new and old values coexist. It's the callers responsibility to not read too old sequence numbers that have been pushed out of the history.

Historic values are evicted by pushing new values onto the queue using push(). The max history from the current sequence number that yields valid values are thus 16 minus number of controls pushed.

The controls at sequence number

◆ push()

bool libcamera::DelayedControls::push ( const ControlList controls)

Push a set of controls on the queue.

[in]controlsList of controls to add to the device queue

Push a set of controls to the control queue. This increases the control queue depth by one.

true if controls are accepted, or false otherwise

◆ reset()

void libcamera::DelayedControls::reset ( )

Reset state machine.

Resets the state machine to a starting position based on control values retrieved from the device.

The documentation for this class was generated from the following files: