How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)

How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)

[Simon Gustafsson]

Bought a rare webcam, which doesn't work in Linux, and would appreciate some
pointers of how to fix that.

1) Is someone already working on this (camera information at the bottom)

2) Where should I begin? My gut feeling is to go for media/video/gspca/ov519.c,
since it has the code for talking to the USB bridge chip (BRIDGE_OVFX2), and
since that code is so neat. If the patches needed to get it working turns out to
be non-estetic, one would have to consider alternatives. I also noticed that
there is some code at media/video/mt9t031.c for talking with my sensor (but it
suggests it can't be used outside of the soc-camera framework (I've never heard
of it before), and I don't know if those parts of the source would be relevant
anyway.

3) Is there a recommended distribution (or kernel revision) when working against
the latest driver sources, or can I just pull the latest sources from git and
expect it to play nicely with something like ubuntu in my case.


----[Hardware information]----
* 3.0MP USB2.0 Digital USB c-mount Camera for Microscopes
* VID:PID 1578:0076
* USB bridge CY7C68013A (aka Cypress FX2LP)
* Sensor: most probably an MT9T031. It responds to the same I2C address, and
when I injected I2C reads to the sensors register 0x00 and 0xFF, I get the
0x1621 response which matches “chip version” according to the datasheet.

BR
/Simon 

Re: How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)

[Jean-Francois Moine]

On Wed, 16 May 2012 22:14:48 +0000 (UTC)
Simon Gustafsson <simong@simong.se> wrote:

> 2) Where should I begin? My gut feeling is to go for media/video/gspca/ov519.c,
> since it has the code for talking to the USB bridge chip (BRIDGE_OVFX2), and

Hi Simon,

The FX2 is a processor, and, in ov519, used as a bridge, it has been
programmed by OmniVision for their sensors. It is quite sure that its
firmware is different in your webcam.

To know more, you should examine USB traces done with some other driver
(ms-windows - the scripts I use to translate these traces for gspca are
in my web site)...

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)

[Simon Gustafsson]

Jean-Francois Moine <moinejf <at> free.fr> writes:

> The FX2 is a processor, and, in ov519, used as a bridge, it has been
> programmed by OmniVision for their sensors. It is quite sure that its
> firmware is different in your webcam.
> 
> To know more, you should examine USB traces done with some other driver

You're right, protocol was completely different, for instance, we can't
read/write to I2C registers of our own choice. Got it working in user space now, 
including all settings available in their windows software (except software-only
settings like gamma etc).

Not sure if it's appropriate with a kernel driver, but since the amount of code
needed would be so small, we might just as well add it. It would probably add
support for these Chinese industrial cameras: DLC130/130L, DLC131/131L, DLC200, 
DLC300, Whitehawk, Goldenhawk, and GoldenEagle. The Windows software lets you
choose between those cameras at start up, and my camera produces images for all
those choices. For some choices, the images are cropped, and/or in gray scale 
with visible bayer pattern (suggesting those cameras would be monochrome).

Have a list of bad things below, would appreciate feedback on these. May amount 
to question whether there should be a kernel driver, in which case I'll just fix 
up the user space code, and host it somewhere.

1a) This FX2 bridge can't be used for auto-detection, since I didn't snoop
anything indicating we could read/write to any sensor registers of our own
choice. Additionally, the Windows software don't choose camera based on VID:PID
(you have the same choice of cameras even without a camera plugged in), so I
assume we need a module parameter for selecting which camera to use. 

1b) I only have one of these cameras, so I can only verify against this one, and 
since mine support the highest resolution, I can't try auto detection methods of 
requesting higher resolutions then the camera supports (hoping it fails), so 
module parameters would be needed here to begin with.

2) I guess the video format won't be supported by many apps (raw byer, 
specifically V4L2_PIX_FMT_SRGGB8). Would it be OK with a module parameter 
switching on kernel space conversion to something universally useful? (would 
happen in a workqueueue of course).

3) The windows software (or FX2 bridge) don't handle selecting lower resolutions 
correctly (it always crops the image, and we get the upper-left portion of the
image). This may be appropriate in many industrial applications. But I still
feel that users won't know why the driver sucks, so I would spontaneously think
we should always emit a couple of KERN_ERR messages describing the possible
problems, and possibly even require the user to configure the camera type module
parameter before opening the device.
  Alternatively, we could provide all resolutions, and all combinations of
color/monochrome all the time, but then only one out of 14 choices would give 
the expected image for a normal user, but industrial users would think seven of 
those 14 modes would be OK.
  This is a big usability point, I would go for an additional module parameter,
"allow_crop", which industrial users could set to get access to cropped images,
so regular users won't have to set more then a "max_resolution" or "camera_type" 
parameter.


But on the bright side, one can have a lot of fun with cheap Chinese industrial 
cameras, like reverse engineering, and writing kernel drivers :)

BR
/Simon