Re: [Media Summit] Imaging Sensor functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave,

On 06/09/2022 18:14, Dave Stevenson wrote:
> Hi All.
> 
> I realise that I'm in a slightly different position from many mainline
> Linux-media developers in that I see multiple use cases for the same
> sensor, rather than a driver predominantly being for one
> product/platform. I'm therefore wanting to look at generic solutions
> and fully featured drivers. Users get to decide the use cases, not the
> hardware designers.
> 
> The issues I've raised are things that I've encountered and would
> benefit from a discussion to get views as to the direction that is
> perceived to be workable. I appreciate that some can not be solved
> immediately, but want to avoid too much bikeshedding in the first
> round of patches.
> What's realistic, and what pitfalls/limitations immediately jump out at people.
> 
> Slides are at https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
> 
> See you on Monday.
> 
>   Dave

Some comments for the meeting on Monday:

- On-sensor temperature sensing:

If a control is used to read this, but the value is
not available yet, then -EACCES can be returned. That's already defined as a valid return
code in the API, it would just need to be extended for this use-case.

- Sync sensors:

Should it be part of the DT? That depends, I think, on whether this is a pure sw mechanism,
or whether the wiring dictates which sensor can be master and which can be slaves. I assume
that at the very least there has to be a way to group sensors that are/can be connected to
the same master sync signal.

- Lens assemblies:

For what it is worth, Cisco uses motor controlled lenses and irises. We extended the camera
controls with these new controls:

#define V4L2_CID_FOCUS_CURRENT                  (V4L2_CID_CAMERA_CLASS_BASE+36)
#define V4L2_CID_IRIS_CURRENT                   (V4L2_CID_CAMERA_CLASS_BASE+38)
#define V4L2_CID_FOCUS_MOTOR_STATUS             (V4L2_CID_CAMERA_CLASS_BASE+41)
#define V4L2_CID_IRIS_MOTOR_STATUS              (V4L2_CID_CAMERA_CLASS_BASE+43)
enum v4l2_motor_status {
        V4L2_MOTOR_STATUS_IDLE                  = (0),
        V4L2_MOTOR_STATUS_MOVING                = (1 << 0),
        V4L2_MOTOR_STATUS_FAILED                = (1 << 1),
        V4L2_MOTOR_STATUS_NOTCALIBRATED         = (1 << 2),
};
#define V4L2_CID_FOCUS_MOTOR_SPEED              (V4L2_CID_CAMERA_CLASS_BASE+46)
#define V4L2_CID_IRIS_MOTOR_SPEED               (V4L2_CID_CAMERA_CLASS_BASE+48)

This worked well for our use-case, but for us userspace has complete knowledge about
the camera assembly properties.

Regards,

	Hans



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux