Hi TJ,
On 12/18/2015 12:48 PM, TJ wrote:
I've been trying to get the 0c45:6270 Vehoh VMS-001 'Discovery' Microscope to
work correctly and discovered what seem to be differences in the bridge_init
and other control commands. The most obvious difference currently is the LEDs
do not turn on, but there seem to be other problems with empty frames,
bad/unrecognised formats, and resolutions, although vlc is able to render a
usable JPEG stream.
I've installed the Windows XP Sonix driver package in a Qemu virtual machine
guest and used wireshark on the host (Kubuntu 15.10, kernel v4.2) to capture
and analyse the control commands.
https://iam.tj/projects/misc/usbmon-0c45-6270.pcapng
That seems to show the bridge_init, and possibly some of the i2c_init, byte
sequences are different. It being the first time I've sniffed a USB driver
though, I'm not yet 100% confident I'm identifying the correct starting point
of the control command flow or the relationships between code and what is on
the wire.
The Windows .inf seems to indicate the chipset is MT9V111:
%USBPCamDesc% = SN.USBPCam,USB\VID_0c45&PID_6270 ; SN9C201 + MI0360\MT9V111
but the sn9c20x is matching as the MT9V011 (I've copied the module to a DKMS
build location and named the clone sn9c20x_vehoh, matching only on 0c45_6270,
to make testing easier):
Right, so it likely actually is an MT9V011, at least we are successfully
reading the sensor-id,
and it has the id of an MT9V011, reading the id is more reliable then relying
on the windows
inf file :)
gspca_main: v2.14.0 registered
gspca_main: sn9c20x_vehoh-2.14.0 probing 0c45:6270
sn9c20x_vehoh: MT9V011 sensor detected
sn9c20x_vehoh: MT9VPRB sensor detected
input: sn9c20x_vehoh as
/devices/pci0000:00/0000:00:1d.7/usb2/2-3/input/input34
sn9c20x_vehoh 2-3:1.0: video1 created
I'd like to know the best way to add the correct command support in this
situation where the existing Linux driver's control data is different to that
in use by the Windows driver?
The best way I can think of to do this is to add a "#define SENSOR_MT9V011_ALT"
to the list
of sensor defines which uses the correct init sequences for your cam, and add a
module
option to override the sd->sensor value from the cmdline, so you would get
something like
this in sd_config():
if (sensor_override != -1)
sd->sensor = sensor_override;
else
sd->sensor = id->driver_info >> 8;
And then you can set the sensor_override module option to SENSOR_MT9V011_ALT
when loading
the module to work with your cam. I realize that this is not ideal, but I'm
afraid it is
the best I can come up with, this at least will allow you to develop support
for your cam,
once we have that we can see if we can find some way to autodetect it.
Regards,
Hans
Do I somehow create another profile in the driver, or directly modify the
existing data and command sequences (this latter would seem to risk regressions
for other users) ?
If creating another profile, how would they differentiate seeing as the device
IDs are identical (I've not seen any sign of obvious version responses so far) ?
My first attempt to add the correct command values for controlling the LEDs
failed, and seems to indicate that more than 1 command is sent to control the
LEDs, unlike the sn9c20x driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
