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 majordomo@xxxxxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
