sn9c20x: incorrect support for 0c45:6270 MT9V011/MT9V111 ?
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_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): 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/pci:00/: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? 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
Re: [mythtv] go7007 based devices
Hans Verkuil wrote: On Thursday 21 January 2010 09:07:47 TJ wrote: Jelle Foks wrote: TJ wrote: I am curious how many people are successfully using go7007 based capture devices with mythtv. I've done some patch work on go7007 driver to make it v4l2 compliant and was thinking of updating mythtv to stop using proprietary go7007 ioctls, but wanted to feel the ground first. -TJ PS: jelle you on this list? Yep, I'm on it, but I guess I don't check on it very often ;-)... You sure don't :) Myself, I'm using a bunch of plextors (with the go7007 chip), both M402's without tuner and TV402's with tuner on my mythbackend in the closet, using Ubuntu with a 2.6.31-11-generic-pae kernel and drivers that I made by combining the driver from the kernel staging tree and an older version that still worked, as I posted (with more details) on my blog at http://go70007.imploder.org . Somebody replied on the blog that it also works on 2.6.32.2, on ARM even... I actually don't know who maintains the go7007 driver in the staging tree, but I don't think it was the v4l guys. Actually, it is. So the linux-media list is the appropriate place to post patches on. It is currently maintained by Pete Eberlein from Sensoray. Try this patch. It runs against kernel source. I tried it on 2.6.32, 2.6.32-r1 and -r2. I basically did some general cleanup on the go7007 driver in the kernel tree, added few standard v4l2 commands and *temporarily* put back in proprietary go7007 ioctls from your package for continued mythtv support. I also added support for ADS Tech DVD Xpress DX2 board (which was the main reason I got into it). It runs well on my DX2 boxes. I've got about 100 of them and am currently testing it on 5. Please post this as well to the linux-media list. It would be great if someone would be willing to do more work on this driver and get it out of staging into the mainline. It's getting close, but it's not there yet. Regards, Hans Hans, My brother, pardon my ignorance, but would you please be so kind and shed some light for me on which way I should go. I was in touch with Pete on linux-media list and he's done quite a bit of work on updating the driver in the current linux-media hg tree. My patch runs against official linux kernel 2.6.32.x but won't run against hg tree. So, my thoughts were to go 2 ways: 1. Update my patch against current linux development kernel (2.6.33-rc5? or -next?) and submit it to be included with the next kernel release. It would still be in the staging category, but at least people will be able to immediately take advantage of the following things: - ADS Tech DX2 support (which I added, actually ported from some earlier release) - Mythtv support (as I included original ioctls) - Mythtv will now be able to be patched to use standard ioctls (I also kept and expanded all standard ioctls) - I found and fixt a few minor bugs 2. Keep working against current linux-media hg tree and tell people to hang tight. This might take a while though, cuz between now and Sept-Oct this year I won't be able to put a lot of time into it (worken on a big project). The things I dunno about and would appreciate anyone shedding some light on are: a. Is the current linux-media hg tree going to be included in 2.6.33 kernel? If so, then option 1 above is out of the question and I will keep working with Pete on the current hg driver. b. If the things didn't change much in the kernel tree since 2.6.32, I can probably quickly update my patch and submit it for inclusion into 2.6.33. If that's the case, which kernel should I make the patch against? Should I just git 2.6.33-rc5? Who do I submit my patch to? Again sorry for my ignorance, I don't do much collaborative work, but I am willing to help out the community. :) -TJ -- 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
Re: go7007 driver -- which program you use for capture
Mauro Carvalho Chehab wrote: It should be against -hg or linux-next tree, otherwise, I can't send it upstream. If you just want to send a patch for people to test, please mark it as RFC, otherwise I'll assume that you're sending a patch for upstream. Since there are more people working on this driver, the better is to add what you have there, to avoid people to do a similar work. OK my brother. I got a hold of the -hg tree and started working off of it. Pete, Question: I was looking through the code and noticed that you turned s2250 driver into v4l2_subdev and go7007 driver initializes it as such and passes it calls via call_all (v4l2_device_call_until_err). How does that affect other drivers? Does that mean they all need to re-written as v4l2_subdev? -TJ -- 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
Re: go7007 driver -- which program you use for capture
Pete Eberlein wrote: On Thu, 2010-01-14 at 15:03 -0500, TJ wrote: Pete, Question: I was looking through the code and noticed that you turned s2250 driver into v4l2_subdev and go7007 driver initializes it as such and passes it calls via call_all (v4l2_device_call_until_err). How does that affect other drivers? Does that mean they all need to re-written as v4l2_subdev? That is correct. The other drivers do not work until they are all converted to the subdev interface. I'm working on the other drivers now. I've finished ov7640 and have started on saa7113. Once the subdev driver conversions are completed, we should be able to move the go7007 driver out of staging. Pete Cool man. I will start working on tw9903 and tw9906, as this is my main area of interest. Is there a template for subdev driver or should I just use your s2250 as an example? -TJ -- 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
Re: go7007 driver -- which program you use for capture
Pete Eberlein wrote: On Fri, 2010-01-08 at 14:07 -0500, TJ wrote: Pete and anybody else out there with go7007 devices, what do you use for capture? I used a modified capture.c, based on http://v4l2spec.bytesex.org/v4l2spec/capture.c OK good. Without GO7007 ioctls, I was only able to get vlc to capture in MJPEG format. Does VLC try to change video parameters after starting the stream? The driver currently doesn't allow that. I think I've seen xawtv try to do that too. I haven't messed with it much, but I think it just uses default driver settings. When I went to Advanced settings in vlc and tried to change some stuff, it didn't work at all. I ended up just hacking up gorecord from the original driver package and got it working that way. I would probably be worthwhile getting vlc to work with go7007. What do you think? -TJ -- 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
Re: go7007 driver -- which program you use for capture
Mauro Carvalho Chehab wrote: TJ wrote: jelle, that you? Here's the patch against go7007 driver in 2.6.32 kernel (run with -p1). The main purpose of the patch is to include support for ADS Tech DVD Xpress DX2 usb capture card and make it usable with v4l2-ctl utility. I also did a general clean-up in a few areas and *temporarily* added back in proprietary go7007 ioctls, so current mythtv users can take advantage of it and to make the gorecord program from wis-go7007 package now work again. Also attached is a stripped down version of gorecord from which I removed all parameter-setting stuff. This version is meant to be used in conjunction with v4l2-ctl or other means of configuring capture parameters. I will try to do mythtv patches next so that it starts using standard v4l2 ioctl calls and we can drop all proprietary stuff in the driver. Please try it and lemme know if it works for you. I've run into a few Ubuntuers as well who were trying to get their boards working as well. The patch doesn't apply on the latest -hg version: patching file drivers/staging/go7007/Kconfig patching file drivers/staging/go7007/go7007-driver.c Hunk #2 succeeded at 225 (offset 1 line). Hunk #3 succeeded at 285 (offset 1 line). patching file drivers/staging/go7007/go7007-usb.c patching file drivers/staging/go7007/go7007-v4l2.c Hunk #1 FAILED at 43. Hunk #2 succeeded at 425 with fuzz 2 (offset 8 lines). Hunk #4 succeeded at 578 (offset 8 lines). Hunk #6 FAILED at 993. Hunk #7 succeeded at 1078 with fuzz 1 (offset -8 lines). Hunk #8 FAILED at 1538. Hunk #9 succeeded at 1672 (offset -18 lines). Hunk #10 succeeded at 1764 (offset -8 lines). 3 out of 10 hunks FAILED -- saving rejects to file drivers/staging/go7007/go7007-v4l2.c.rej patching file drivers/staging/go7007/s2250-board.c Hunk #1 FAILED at 357. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/s2250-board.c.rej patching file drivers/staging/go7007/wis-i2c.h patching file drivers/staging/go7007/wis-saa7113.c patching file drivers/staging/go7007/wis-saa7115.c patching file drivers/staging/go7007/wis-tw2804.c patching file drivers/staging/go7007/wis-tw9903.c Hunk #1 FAILED at 152. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/wis-tw9903.c.rej patching file drivers/staging/go7007/wis-tw9906.c Patch doesn't apply Mauro, brother, this patch is for in-kernel go7007 driver. It has to be run against kernel source 2.6.32. (IIRC it will also run against 2.6.31) It won't run against current v4l-dvb tree, as Pete has done quite a few changes since then. When I get a chance, I will start working against current version. Also, you shouldn't re-add the proprietary API but, instead, to port it to use the API support for compressed stuff. I did add support for standard vidioc_s/g_ext_ctrls API stuff and that's what I am actually using currently. I merely kept the proprietary ioctls so that mythtv users can start using the driver as well until somebody (me?) patches mythtv to use the standard APIs. -TJ Cheers, Mauro. -- 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
go7007 driver -- which program you use for capture
Pete and anybody else out there with go7007 devices, what do you use for capture? Without GO7007 ioctls, I was only able to get vlc to capture in MJPEG format. -TJ -- 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
Re: go7007 driver -- which program you use for capture
jelle, that you?
Here's the patch against go7007 driver in 2.6.32 kernel (run with -p1).
The main purpose of the patch is to include support for ADS Tech DVD Xpress DX2
usb capture card and make it usable with v4l2-ctl utility.
I also did a general clean-up in a few areas and *temporarily* added back in
proprietary go7007 ioctls, so current mythtv users can take advantage of it and
to make the gorecord program from wis-go7007 package now work again.
Also attached is a stripped down version of gorecord from which I removed all
parameter-setting stuff. This version is meant to be used in conjunction with
v4l2-ctl or other means of configuring capture parameters.
I will try to do mythtv patches next so that it starts using standard v4l2 ioctl
calls and we can drop all proprietary stuff in the driver.
Please try it and lemme know if it works for you. I've run into a few Ubuntuers
as well who were trying to get their boards working as well.
-TJ
Jarod Wilson wrote:
On Fri, Jan 8, 2010 at 2:07 PM, TJ one.timothy.jo...@gmail.com wrote:
Pete and anybody else out there with go7007 devices, what do you use for
capture?
Without GO7007 ioctls, I was only able to get vlc to capture in MJPEG format.
Never actually used one myself, but MythTV has support for at least
the Plextor ConvertX go7007-based devices.
diff -U 3 -H -d -I' ' -x' .*' -r -N --
linux-2.6.32-gentoo/drivers/staging/go7007/Kconfig
linux-2.6.32-gentoo_DX2/drivers/staging/go7007/Kconfig
--- linux-2.6.32-gentoo/drivers/staging/go7007/Kconfig 2010-01-08
16:20:20.0 -0500
+++ linux-2.6.32-gentoo_DX2/drivers/staging/go7007/Kconfig 2010-01-08
10:24:34.0 -0500
@@ -77,6 +77,16 @@
To compile this driver as a module, choose M here: the
module will be called wis-tw9903
+config VIDEO_GO7007_TW9906
+ tristate TW9906 subdev support
+ depends on VIDEO_GO7007
+ default N
+ ---help---
+ This is a video4linux driver for the TW9906 sub-device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wis-tw9906
+
config VIDEO_GO7007_UDA1342
tristate UDA1342 subdev support
depends on VIDEO_GO7007
diff -U 3 -H -d -I' ' -x' .*' -r -N --
linux-2.6.32-gentoo/drivers/staging/go7007/go7007-driver.c
linux-2.6.32-gentoo_DX2/drivers/staging/go7007/go7007-driver.c
--- linux-2.6.32-gentoo/drivers/staging/go7007/go7007-driver.c 2010-01-08
16:20:20.0 -0500
+++ linux-2.6.32-gentoo_DX2/drivers/staging/go7007/go7007-driver.c
2010-01-08 10:24:34.0 -0500
@@ -170,6 +171,17 @@
/* Set GPIO pin 0 to be an output (audio clock control) */
go7007_write_addr(go, 0x3c82, 0x0001);
go7007_write_addr(go, 0x3c80, 0x00fe);
+ break;
+ case GO7007_BOARDID_ADS_USBAV_709:
+ /* GPIO pin 0: audio clock control */
+ /* pin 2: TW9906 reset */
+ /* pin 3: capture LED */
+ go7007_write_addr(go, 0x3c82, 0x000d);
+ go7007_write_addr(go, 0x3c80, 0x00f2);
+ break;
+ default:
+ /* No special setup */
+ break;
}
return 0;
}
@@ -212,6 +224,9 @@
case I2C_DRIVERID_WIS_TW9903:
modname = wis-tw9903;
break;
+ case I2C_DRIVERID_WIS_TW9906:
+ modname = wis-tw9906;
+ break;
case I2C_DRIVERID_WIS_TW2804:
modname = wis-tw2804;
break;
@@ -269,6 +284,12 @@
go-i2c_adapter_online = 1;
}
if (go-i2c_adapter_online) {
+ if (go-board_id == GO7007_BOARDID_ADS_USBAV_709) {
+ /* Reset the TW9906 */
+ go7007_write_addr(go, 0x3c82, 0x0009);
+ msleep(50);
+ go7007_write_addr(go, 0x3c82, 0x000d);
+ }
for (i = 0; i go-board_info-num_i2c_devs; ++i)
init_i2c_module(go-i2c_adapter,
go-board_info-i2c_devs[i].type,
diff -U 3 -H -d -I' ' -x' .*' -r -N --
linux-2.6.32-gentoo/drivers/staging/go7007/go7007-usb.c
linux-2.6.32-gentoo_DX2/drivers/staging/go7007/go7007-usb.c
--- linux-2.6.32-gentoo/drivers/staging/go7007/go7007-usb.c 2010-01-08
16:20:20.0 -0500
+++ linux-2.6.32-gentoo_DX2/drivers/staging/go7007/go7007-usb.c 2010-01-08
10:24:34.0 -0500
@@ -444,6 +444,44 @@
},
};
+static struct go7007_usb_board board_ads_usbav_709 = {
+ .flags = GO7007_USB_EZUSB,
+ .main_info = {
+ .firmware= go7007tv.bin,
+ .flags = GO7007_BOARD_HAS_AUDIO |
+ GO7007_BOARD_USE_ONBOARD_I2C,
+ .audio_flags = GO7007_AUDIO_I2S_MODE_1 |
+ GO7007_AUDIO_I2S_MASTER
