Re: [Media Summit] Imaging Sensor functionality

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Hans,

On Sat, Sep 10, 2022 at 02:50:10PM +0200, Hans Verkuil wrote:
> 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.

Where does userspace get that information from ?

-- 
Regards,

Laurent Pinchart