Re: [PATCH 3/3] [media] uvcvideo: skip non-extension unit controls on Oculus Rift Sensors

[Philipp Zabel <philipp.zabel@gmail.com>]

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