On 10/09/2022 18:17, Laurent Pinchart wrote: > 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 ? > >From the software engineers :-) We designed the cameras, so we know how to operate them. I'm not entirely sure if that's what you meant, though. Regards, Hans
