Hi Laurent, Am Dienstag, den 25.07.2017, 02:10 +0300 schrieb Laurent Pinchart: > > > Yes, I think a device-specific driver would make sense, especially if > > > we can implement support for the sensor as a standalone V4L2 subdev > > > driver. The device only fakes UVC compatibility :-( > > > > When you say standalone driver, do you mean I can reuse uvcvideo > > device/stream/chain handling, and just replace the control handling? > > No, I mean a completely separate driver. Given that the driver will be used > for a single device, you can hardcode lots of assumptions and don't have to > parse UVC descriptors. I see, I was hoping I wouldn't have to (re)write all the video transfer and timing parts myself. > > I'll try this, but it isn't a straightforward as I initially thought. > > For example, the mt9v032 subdev driver expects to have control over > > power during probe and s_power. But in this case power is controlled by > > UVC streaming. > > How does that work with the device ? If the sensor is powered off until you > start video streaming, I assume it won't reply to I2C commands. Do you need to > configure it after stream start ? Yes. The webcam controllers replay the stored initialization sequences to the sensors on startup, like any other usb cameras, and start streaming images. That is why I added them to uvcvideo in the first place. After the stream has started, I'd like to change the controls from the defaults (enable AEC/AGC or increase gain for normal camera use, or reduce gain and exposure time and enable trigger mode for Rift tracking). Unfortunatley those can only be changed via I2C. > > I'd either have to modify the subdev driver to support a passive mode or > > fake the chip id register reads in the i2c adapter driver to make mt9v032 > > probe at all. > > > > Do you have any further comments on the first two patches? > > Just that those patches are not needed if we implement a driver specific to > the Oculus Rift :-) Ok. I'll give that a shot then. regards Philipp
