Thread (17 messages) 17 messages, 5 authors, 2011-09-26

Re: [RFC] New class for low level sensors controls?

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: 2011-09-26 09:54:23

Hi Hans,

On Monday 26 September 2011 11:51:05 Hans Verkuil wrote:
On Tuesday, September 06, 2011 13:36:53 Sakari Ailus wrote:
quoted
Hi all,

We are beginning to have raw bayer image sensor drivers in the mainline.
Typically such sensors are not controlled by general purpose applications
but e.g. require a camera control algorithm framework in user space. This
needs to be implemented in libv4l for general purpose applications to
work properly on this kind of hardware.

These sensors expose controls such as

- Per-component gain controls. Red, blue, green (blue) and green (red)

  gains.

- Link frequency. The frequency of the data link from the sensor to the

  bridge.

- Horizontal and vertical blanking.

None of these controls are suitable for use of general purpose
applications (let alone the end user!) but for the camera control
algorithms.

We have a control class called V4L2_CTRL_CLASS_CAMERA for camera
controls. However, the controls in this class are relatively high level
controls which are suitable for end user. The algorithms in the libv4l
or a webcam could implement many of these controls whereas I see that
only
V4L2_CID_EXPOSURE_ABSOLUTE might be implemented by raw bayer sensors.

My question is: would it make sense to create a new class of controls for
the low level sensor controls in a similar fashion we have a control
class for the flash controls?
I'm plowing through all the mails on this list that piled up during the
last 3-4 weeks, so my reply is a bit late :-)

I don't believe a new class is the right approach. If such controls are
part of a sub-device, then they can be marked 'private', which means they
are only accessible through the subdev device node.
We're not trying to hide controls, but to standardize low-level sensor 
controls that are common across many sensors. They don't really belong to any 
of the existing classes, hence the idea of creating a new class for them.
For low-level controls that are part of the bridge chip there is currently
no suitable way of hiding them.

In that case the best approach would be to add a new control flag called
V4L2_CTRL_FLAG_HIDE (or _INVISIBLE, or _LOW_LEVEL, or something similar).
Applications can filter such controls and not show them.

I've toyed with this idea before, but of course it has the disadvantage of
requiring application support.

One alternative to this is to let QUERYCTRL skip such hidden controls
unless instructed otherwise (e.g. by adding a V4L2_CTRL_FLAG_SHOW_ALL to
the control's id). But I think that's getting a bit too complex.

I think adding a 'HIDE' flag of some sort is a good idea. It's simple and
does the job.
-- 
Regards,

Laurent Pinchart
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help