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
