Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet
On Fri, 31 May 2013 10:08:27 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 30 May 2013 21:00:01 +0200 Jon Arne Jørgensen jona...@jonarne.no escreveu: On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote: I would rather have the platform_data provide the new table. Or if you think bulk of the table will be the same for most users, then perhaps add there an enum saying which table to use - and name the tables according to the chip variant it applies to. I think the bulk of the table will be the same for all drivers. It's one bit here and one bit there that needs changing. As the driver didn't support platform data. Changing to a new init table for the drivers that implement platform_data shouldn't cause any regressions. There are several things that are very bad on passing a table via platform data: Sorry, my wording was self-conflicting. The intention was to suggest providing an enum saying which table to use. Not that the platform data would provide the whole table. 1) you're adding saa711x-specific data at the bridge driver, so, the saa711x code is spread on several places at the long term; 2) some part of the saa711x code may override the data there, as it is not aware about what bits should be preserved from the new device; 3) due (2), latter changes on the code are more likely to cause regressions; 4) also due to (2), some hacks can be needed, in order to warn saa711x to handle some things differently. Agreed. That's why it is a way better to add meaningful parameters telling what bits are needed for the driver to work with the bridge. That's also why we do this with all other drivers. Based on the latest patch, more of these bits need to be controlled individually than I figured. So yes, individual meaningful bits do make the most sense. Thanks, Timo -- 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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet
On Thu, 30 May 2013 07:21:36 +0200 Jon Arne Jørgensen jona...@jonarne.no wrote: On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote: Mauro Carvalho Chehab mche...@redhat.com wrote: Em Wed, 29 May 2013 22:41:16 +0200 Jon Arne Jørgensen jona...@jonarne.no escreveu: Change all default values in the initial setup table to match the table in the datasheet. This is not a good idea, as it can produce undesired side effects on the existing drivers that depend on it, and can't be easily tested. Please, don't change the current default. It is, of course, OK to change them if needed via the information provided inside the platform data. I was going to make a comment along the same line as Mauro. Please leave the driver defaults alone. It is almost impossible to regression test all the different devices with a SAA7113 chip, to ensure the change doesn't cause someone's device to not work properly. You guys are totally right. What if I clone the original saa7113_init table into a new one, and make the driver use the new one if the calling driver sets platform_data. Something like this? switch (state-ident) { case V4L2_IDENT_SAA7111: case V4L2_IDENT_SAA7111A: saa711x_writeregs(sd, saa7111_init); break; case V4L2_IDENT_GM7113C: case V4L2_IDENT_SAA7113: - saa711x_writeregs(sd, saa7113_init); + if (client-dev.platform_data) + saa711x_writeregs(sd, saa7113_new_init); + else + saa711x_writeregs(sd, saa7113_init); I would rather have the platform_data provide the new table. Or if you think bulk of the table will be the same for most users, then perhaps add there an enum saying which table to use - and name the tables according to the chip variant it applies to. - Timo -- 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: Terratec Grabby hwrev 2
On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen jona...@jonarne.no wrote: On Thu, Mar 28, 2013 at 04:54:59PM +0200, Timo Teras wrote: On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras timo.te...@iki.fi wrote: On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels Still have not figured out this one. Could be probably related to the saa7113 differences. With NTSC signal: - unable to get a lock, and the whole picture looks garbled NTSC started working after I removed all the saa711x writes to following registers: R_14_ANAL_ADC_COMPAT_CNTL R_15_VGATE_START_FID_CHG R_16_VGATE_STOP R_17_MISC_VGATE_CONF_AND_MSB This is the exact same behavior as i see on the gm7113c chip in the stk1160, and the smi2021 devices. See here: http://www.spinics.net/lists/linux-media/msg63163.html Thanks. I tested the patch and it detects it properly, and I get picture. However, there's problems synchronizing to my PAL signal. The picture jumps once in a while. I guess the problem is in the init sequence. The W7 driver had following differences sequence changes compared to saa7113_init: - R_02_INPUT_CNTL_1, 0xc2, + R_02_INPUT_CNTL_1, 0xc0, - R_04_INPUT_CNTL_3, 0x00, - R_05_INPUT_CNTL_4, 0x00, - R_06_H_SYNC_START, 0x89, + R_06_H_SYNC_START, 0xeb, - R_12_RT_SIGNAL_CNTL, 0x07, + R_12_RT_SIGNAL_CNTL, 0xe7, - R_14_ANAL_ADC_COMPAT_CNTL, 0x00, - R_15_VGATE_START_FID_CHG, 0x00, - R_16_VGATE_STOP, 0x00, - R_17_MISC_VGATE_CONF_AND_MSB, 0x00, Seems that R_14 is filtered in your patch, but other changes are not taken into account. Otherwise, the patchset looks good. - Timo -- 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: Terratec Grabby hwrev 2
On Thu, 2 May 2013 10:04:56 +0300 Timo Teras timo.te...@iki.fi wrote: On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen jona...@jonarne.no wrote: On Thu, Mar 28, 2013 at 04:54:59PM +0200, Timo Teras wrote: On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras timo.te...@iki.fi wrote: On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels Still have not figured out this one. Could be probably related to the saa7113 differences. With NTSC signal: - unable to get a lock, and the whole picture looks garbled NTSC started working after I removed all the saa711x writes to following registers: R_14_ANAL_ADC_COMPAT_CNTL R_15_VGATE_START_FID_CHG R_16_VGATE_STOP R_17_MISC_VGATE_CONF_AND_MSB This is the exact same behavior as i see on the gm7113c chip in the stk1160, and the smi2021 devices. See here: http://www.spinics.net/lists/linux-media/msg63163.html Thanks. I tested the patch and it detects it properly, and I get picture. However, there's problems synchronizing to my PAL signal. The picture jumps once in a while. I guess the problem is in the init sequence. The W7 driver had following differences sequence changes compared to saa7113_init: - R_02_INPUT_CNTL_1, 0xc2, + R_02_INPUT_CNTL_1, 0xc0, - R_04_INPUT_CNTL_3, 0x00, - R_05_INPUT_CNTL_4, 0x00, - R_06_H_SYNC_START, 0x89, + R_06_H_SYNC_START, 0xeb, - R_12_RT_SIGNAL_CNTL, 0x07, + R_12_RT_SIGNAL_CNTL, 0xe7, - R_14_ANAL_ADC_COMPAT_CNTL, 0x00, - R_15_VGATE_START_FID_CHG, 0x00, - R_16_VGATE_STOP, 0x00, - R_17_MISC_VGATE_CONF_AND_MSB, 0x00, Seems that R_14 is filtered in your patch, but other changes are not taken into account. Otherwise, the patchset looks good. Not sure if part of the problems were related to the fact that I tried this patch set first with 3.8.10. And that had problems. Now I'm using 3.9.0 with the above mentioned patchset, and my additional patch (below). This seems to work nicely. In any case it strongly looks like Terratec Grabby hwrev2 has also the gm7113c chip; I still have not opened one to look, though. --- a/drivers/media/i2c/saa7115.c +++ b/drivers/media/i2c/saa7115.c @@ -450,6 +450,28 @@ /* == SAA7715 VIDEO templates (end) === */ /* == GM7113C VIDEO templates = */ +static const unsigned char gm7113c_init[] = { + R_01_INC_DELAY, 0x08, + R_02_INPUT_CNTL_1, 0xc0, + R_03_INPUT_CNTL_2, 0x30, + R_06_H_SYNC_START, 0xeb, + R_07_H_SYNC_STOP, 0x0d, + R_08_SYNC_CNTL, 0x88, + R_09_LUMA_CNTL, 0x01, + R_0A_LUMA_BRIGHT_CNTL, 0x80, + R_0B_LUMA_CONTRAST_CNTL, 0x47, + R_0C_CHROMA_SAT_CNTL, 0x40, + R_0D_CHROMA_HUE_CNTL, 0x00, + R_0E_CHROMA_CNTL_1, 0x01, + R_0F_CHROMA_GAIN_CNTL, 0x2a, + R_10_CHROMA_CNTL_2, 0x08, + R_11_MODE_DELAY_CNTL, 0x0c, + R_12_RT_SIGNAL_CNTL, 0xe7, + R_13_RT_X_PORT_OUT_CNTL, 0x00, + + 0x00, 0x00 +}; + static const unsigned char gm7113c_cfg_60hz_video[] = { R_08_SYNC_CNTL, 0x68, /* 0xBO: auto detection, 0x68 = NTSC */ R_0E_CHROMA_CNTL_1, 0x07, /* video autodetection is on */ @@ -1771,9 +1793,11 @@ case
Re: Terratec Grabby hwrev 2
On Mon, 29 Apr 2013 15:26:18 +0300 Timo Teras timo.te...@iki.fi wrote: When comparing these two picture, you see that the frame is offset with one or two pixels in x-direction. Perhaps this is a byte offset, and in RGB format causes color values to be connected to wrong pixel. As final note, now I hooked the device on faster machine, and the AC97 detection seems random. It seemed to work with the slower machine reliably after I had it do the saa7113 initialization. So sounds like some sort of timing issue. More details please. ;) Do you mean that Config register raw data (see dmesg output) value varies ? I traced the USB init sequence that windows does. It is as follows (simplified by removing some other register / eeprom reads): em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff); msleep(20); em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd); msleep(100); em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d); msleep(60); em28xx_write_reg(dev, EM28XX_R12_VINENABLE, 0x24); em28xx_write_reg(dev, 0x0d, 0x42); Will test if it makes the detection of the audio chip more reliable. The patch added is below. Seems that detecting the audio chip is now a lot more reliable. So far I have not seen failures. Not sure if the GPIO twidling drives something - or if it's just the additional delay fixing things. --- a/drivers/media/usb/em28xx/em28xx-cards.c +++ b/drivers/media/usb/em28xx/em28xx-cards.c @@ -2479,6 +2479,19 @@ em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd); msleep(70); break; + + case EM2860_BOARD_TERRATEC_GRABBY: + em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff); + msleep(20); + em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd); + msleep(100); + em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd); + msleep(100); + em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d); + msleep(60); + em28xx_write_reg(dev, EM28XX_R12_VINENABLE, 0x24); + em28xx_write_reg(dev, 0x0d, 0x42); + break; } em28xx_gpio_set(dev, dev-board.tuner_gpio); -- 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: Terratec Grabby hwrev 2
On Fri, 05 Apr 2013 17:33:07 +0200 Frank Schäfer fschaefer@googlemail.com wrote: Am 03.04.2013 10:27, schrieb Timo Teras: I did not test VBI, so I'm unsure if it works or not. The em2860 supports VBI, so VBI mode is used. You can force the normal mode with module parameter disable_vbi=1 Right. Tested that now. Except the green line at the bottom which I'm seeing, too. Try the module parameter disable_vbi=1 and the distortion/artifacts/offset should change a bit. I wouldn't wonder if we encounter multiple issues here which are interfering with each other... :( The green line goes away with disable_vbi=1. However, I will then see the top first line having some morse code like garbage on it. So yes, sounds like R1D_VSTART setting needs fixing. When comparing these two picture, you see that the frame is offset with one or two pixels in x-direction. Perhaps this is a byte offset, and in RGB format causes color values to be connected to wrong pixel. As final note, now I hooked the device on faster machine, and the AC97 detection seems random. It seemed to work with the slower machine reliably after I had it do the saa7113 initialization. So sounds like some sort of timing issue. More details please. ;) Do you mean that Config register raw data (see dmesg output) value varies ? I traced the USB init sequence that windows does. It is as follows (simplified by removing some other register / eeprom reads): em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xff); msleep(20); em28xx_write_reg(dev, EM28XX_R08_GPIO, 0xfd); msleep(100); em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x7d); msleep(60); em28xx_write_reg(dev, EM28XX_R12_VINENABLE, 0x24); em28xx_write_reg(dev, 0x0d, 0x42); Will test if it makes the detection of the audio chip more reliable. - Timo -- 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: Terratec Grabby hwrev 2
On Tue, 02 Apr 2013 18:39:25 +0200 Frank Schäfer fschaefer@googlemail.com wrote: Am 02.04.2013 07:43, schrieb Timo Teras: On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer fschaefer@googlemail.com wrote: Am 30.03.2013 10:54, schrieb Timo Teras: On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. So, maybe it does a different crop setup at em28xx. I did an analysis of the register setups of em28xx and found the following differences: 1. Different crop settings EM28XX_R1D_VSTART, EM28XX_R1F_CHEIGHT and EM28XX_R2B_YMAX set by W7 driver were divided by two compared to the linux driver. Seems that linux driver did just this before commit c2a6b54. I also found the patch https://patchwork.kernel.org/patch/1272051/ to restore the original behaviour, but somehow it was disregarded and commit 0bc9c89 was done instead. The mentioned patch though does not fix R1D setting though. Can you post the settings the Windows driver uses for these registers ? Don't worry about registers 0x28-0x2B, different values shouldn' matter. See http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/57039. Yes, it would seem registers 0x28-0x2B do not have great significance in the video we get out of it. The full sequence the W7 driver does for PAL video is: EM28XX_R20_YGAIN0x00 EM28XX_R22_UVGAIN 0x00 EM28XX_R06_I2C_CLK 0x40 EM28XX_R15_RGAIN0x20 EM28XX_R16_GGAIN0x20 EM28XX_R17_BGAIN0x20 EM28XX_R18_ROFFSET 0x00 EM28XX_R19_GOFFSET 0x00 EM28XX_R1A_BOFFSET 0x00 EM28XX_R23_UOFFSET 0x00 EM28XX_R24_VOFFSET 0x00 EM28XX_R26_COMPR0x00 EM28XX_R13_??? 0x08 (Note: we do not set this at all) I've seen this write to reg 0x13 with my webcams, too. Unfortunately, we don't know what it means. But according to my tests, it is not needed. Right, it is not strictly needed. EM28XX_R27_OUTFMT 0x34 EM28XX_R10_VINMODE 0x00 We set vinmode to 0x10 (see em28xx_init_dev() in em28xx-cards.c). No idea what the values mean. Might be worth testing with 0x00. Did not try, but seems it did not make any great difference either. EM28XX_R28_XMIN 0x01 EM28XX_R29_XMAX 0xB3 EM28XX_R2A_YMIN 0x01 EM28XX_R2B_YMAX 0x47 (We set 0x8e, i think) Yes, we set to EM28XX_R2B_YMAX to 0x8f, the other values are the same as used by the driver. 0x47 is 0x8f / 2, so what the Windows driver seems to do here is to use the field height instead of the image height (interlaced mode) which is the same what we did in the past in our driver. Anyway, some other device like the MSI DigiVox ATSC (PAL or NTSC ?, interlaced), Silvercrest webcam 1.3MPix (640x480, progressive) use the following values: 0x01, 0xFF, 0x01, 0xFF. And the Speedlink VAD Laplace webcam for example uses the following values: 0x1B, 0x83, 0x13, 0x63(320x240, 640x480, progressive) 0x6B, 0xD3, 0x57, 0xA7(1280x1024, progressive) 0x93, 0xFB, 0x6D, 0xBD(1600x1200, progressive) So which formula should we use ? Suggestions ? ;) Not really. And yes, seems it does not matter much. I took the below referred image grabs with unmodified em28xx, and they look pretty much the same compared to the results of em28xx patched as described before. As said before, we didn't notice any difference in the device behavior when changing the values so far. So let's stay with the current formula. Yeah. EM28XX_R1C_HSTART 0x00 EM28XX_R1D_VSTART 0x01 (We set 0x02) In VBI mode, yes, without VBI we use 0x00. I don't know if a 1 Pixel offset makes a big difference. But looking at the comment in em28xx_resolution_set(), an offset of 2 pixels seems to make a bigger difference for VBI devices, which makes my alert bells ringing... I did not test VBI, so I'm unsure if it works or not. [snip] Oh, would it then make sense to disable all the non-16bpp formats for the time being? Maybe. But in practice, nearly all TV/DVB application (or libv4l2) are selecting a 16 bit format, so this doesn't cause too much trouble. ffmpeg however seems to be the exception ;) The other exception might be webcam applications. Seems the exception is applications using libv4l2 and requesting primarly a format that is not native to the device. I'm also getting a usable image with the 8 bit formats, so it's not completely broken. Anyway, sooner or later we will have to fix the 8 bit formats, because for webcams with higher resolutions (e.g. = 1280x1024) 16 bit formats cannot be used anymore... ;) Basically, I got mostly OK picture, but areas with all-black and all-white next
Re: Terratec Grabby hwrev 2
On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer fschaefer@googlemail.com wrote: Am 30.03.2013 10:54, schrieb Timo Teras: On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. So, maybe it does a different crop setup at em28xx. I did an analysis of the register setups of em28xx and found the following differences: 1. Different crop settings EM28XX_R1D_VSTART, EM28XX_R1F_CHEIGHT and EM28XX_R2B_YMAX set by W7 driver were divided by two compared to the linux driver. Seems that linux driver did just this before commit c2a6b54. I also found the patch https://patchwork.kernel.org/patch/1272051/ to restore the original behaviour, but somehow it was disregarded and commit 0bc9c89 was done instead. The mentioned patch though does not fix R1D setting though. Can you post the settings the Windows driver uses for these registers ? Don't worry about registers 0x28-0x2B, different values shouldn' matter. See http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/57039. Yes, it would seem registers 0x28-0x2B do not have great significance in the video we get out of it. The full sequence the W7 driver does for PAL video is: EM28XX_R20_YGAIN0x00 EM28XX_R22_UVGAIN 0x00 EM28XX_R06_I2C_CLK 0x40 EM28XX_R15_RGAIN0x20 EM28XX_R16_GGAIN0x20 EM28XX_R17_BGAIN0x20 EM28XX_R18_ROFFSET 0x00 EM28XX_R19_GOFFSET 0x00 EM28XX_R1A_BOFFSET 0x00 EM28XX_R23_UOFFSET 0x00 EM28XX_R24_VOFFSET 0x00 EM28XX_R26_COMPR0x00 EM28XX_R13_??? 0x08 (Note: we do not set this at all) EM28XX_R27_OUTFMT 0x34 EM28XX_R10_VINMODE 0x00 EM28XX_R28_XMIN 0x01 EM28XX_R29_XMAX 0xB3 EM28XX_R2A_YMIN 0x01 EM28XX_R2B_YMAX 0x47 (We set 0x8e, i think) EM28XX_R1C_HSTART 0x00 EM28XX_R1D_VSTART 0x01 (We set 0x02) EM28XX_R1E_CWIDTH 0xB4 EM28XX_R1F_CHEIGHT 0x48 (We set 0x8f, or 0x90) EM28XX_R1B_OFLOW0x00 (Tuner and AC97 config takes place here) EM28XX_R0E_AUDIOSRC 0x8f EM28XX_R21_YOFFSET 0x08 (We set 0x10) EM28XX_R20_YGAIN0x10 EM28XX_R22_UVGAIN 0x10 EM28XX_R14_GAMMA0x32 (We set 0x20) EM28XX_R25_SHARPNESS0x02 (We set 0x00) EM28XX_R26_COMPR0x00 EM28XX_R27_OUTFMT 0x34 EM28XX_R11_VINCTRL 0x11 EM28XX_R1B_OFLOW0x00 EM28XX_R12_VINENABLE0x67 EM28XX_R22_UVGAIN 0x10 EM28XX_R20_YGAIN0x10 EM28XX_R0E_AUDIOSRC 0x8f 2. Different outfmt used It seems that ffmpeg defaults to v4l default, which somehow apparently resulted in EM28XX_OUTFMT_RGB_8_RGRG set. When forcing ffmpeg to set yuyv422 or EM28XX_OUTFMT_YUV422_Y0UY1V the color distortions vanished. I'm unsure if the distiortion comes from ffmpeg doing some automatic conversions, or from v4l kernel driver. The easiest way to test the drivers output formats is to use qv4l2 with the device opened in raw mode (command line option '-r' or 'Open raw device' from the 'File' menu). In raw mode, you can be sure that the selected format is always the actually used format (otherwise libv4l2 is used which selects what it thinks is the best source format for the conversion into the selected format. Ah, ok. So libv4l2 can be doing stuff underneath also. I think in my setup yuv420p is the preferred one (encoding to h264 with baseline profile). Now that I figured what goes wrong, this is not a big issue. I hate to say that, but currently you shouldn't expect anything else than the 16 bit formats to work properly. :( The code assumes 16 bit pixel width in several places (initially YUV422 was the only supported format). Some of these bugs are easy to find (e.g. in em28xx_copy_video() ), some are hidden... I didn't have enough time yet to track them all down and all my attempts to fix parts of the code resulted in an even worse picture so far. Oh, would it then make sense to disable all the non-16bpp formats for the time being? Basically, I got mostly OK picture, but areas with all-black and all-white next to each other got distorted (e.g. subtitles). Though, it might be an idea to set the default outfmt to something that is known to work. So I'm wondering if this could be fixed easily? YUYV422 should have also better quality, so it would make sense to select it instead of the other one. The driver selects EM28XX_OUTFMT_YUV422_Y0UY1V as default format, so it must be ffmpeg that selects EM28XX_OUTFMT_RGB_8_RGRG. Yes, starting to sound like that. So seems that now the device is working properly. Basically we need the following changes: 1. saa7113 id ignore (or autodetect, and fallback to forced type) 2. saa7113 not writing to the registers
Re: Terratec Grabby hwrev 2
On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. So, maybe it does a different crop setup at em28xx. I did an analysis of the register setups of em28xx and found the following differences: 1. Different crop settings EM28XX_R1D_VSTART, EM28XX_R1F_CHEIGHT and EM28XX_R2B_YMAX set by W7 driver were divided by two compared to the linux driver. Seems that linux driver did just this before commit c2a6b54. I also found the patch https://patchwork.kernel.org/patch/1272051/ to restore the original behaviour, but somehow it was disregarded and commit 0bc9c89 was done instead. The mentioned patch though does not fix R1D setting though. 2. Different outfmt used It seems that ffmpeg defaults to v4l default, which somehow apparently resulted in EM28XX_OUTFMT_RGB_8_RGRG set. When forcing ffmpeg to set yuyv422 or EM28XX_OUTFMT_YUV422_Y0UY1V the color distortions vanished. I'm unsure if the distiortion comes from ffmpeg doing some automatic conversions, or from v4l kernel driver. Though, it might be an idea to set the default outfmt to something that is known to work. So I'm wondering if this could be fixed easily? YUYV422 should have also better quality, so it would make sense to select it instead of the other one. -- So seems that now the device is working properly. Basically we need the following changes: 1. saa7113 id ignore (or autodetect, and fallback to forced type) 2. saa7113 not writing to the registers 14-17 in case it's not the original chip (id not present) 3. em28xx crop height/vstart to divided by 2 in interlaced mode 4. (optionally) em28xx outfmt should default to YUYV422 I can post a patch for 3, but for others I'm not fully certain about implementation details. With few pointers, I could probably produce patches, though. But I would be also happy to just test what ever you come up with. Thanks, Timo -- 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: [PATCH] em28xx: ignore isoc DVB USB endpoints with wMaxPacketSize = 0 bytes for all alt settings
On Wed, 27 Mar 2013 21:07:41 +0100 Frank Schäfer fschaefer@googlemail.com wrote: Some devices without DVB support (such as the Terratec Grabby and Easycap DC-60) provide isochronous DVB USB endpoints with wMaxPacketSize set to 0 bytes for all alt settings. Ignore these endpoints and avoid registering a DVB device node and loading the DVB driver extension. Signed-off-by: Frank Schäfer fschaefer@googlemail.com Cc: sta...@kernel.org Tested-by: Timo Teräs timo.te...@iki.fi Fixes the false DVB detection on my Terratec Grabby. -- 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: Terratec Grabby hwrev 2
On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. - Timo -- 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: Terratec Grabby hwrev 2
On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels With NTSC signal: - unable to get a lock, and the whole picture looks garbled On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. - Timo -- 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: Terratec Grabby hwrev 2
On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras timo.te...@iki.fi wrote: On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels Still have not figured out this one. Could be probably related to the saa7113 differences. With NTSC signal: - unable to get a lock, and the whole picture looks garbled NTSC started working after I removed all the saa711x writes to following registers: R_14_ANAL_ADC_COMPAT_CNTL R_15_VGATE_START_FID_CHG R_16_VGATE_STOP R_17_MISC_VGATE_CONF_AND_MSB - Timo -- 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: Terratec Grabby hwrev 2
On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Which does not look good. i2c_scan=1 on modprobe gives: em2860 #0: found i2c device @ 0x4a [saa7113h] em2860 #0: found i2c device @ 0xa0 [eeprom] em2860 #0: found i2c device @ 0xa2 [???] em2860 #0: found i2c device @ 0xa4 [???] em2860 #0: found i2c device @ 0xa6 [???] em2860 #0: found i2c device @ 0xa8 [???] em2860 #0: found i2c device @ 0xaa [???] em2860 #0: found i2c device @ 0xac [???] em2860 #0: found i2c device @ 0xae [???] - Timo -- 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: Terratec Grabby hwrev 2
On Wed, 27 Mar 2013 18:37:26 +0100 Frank Schäfer fschaefer@googlemail.com wrote: Am 25.03.2013 18:08, schrieb Timo Teras: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1249.600246] em28xx: New device TerraTec Electronic GmbH TerraTec Grabby @ 480 Mbps (0ccd:0096, inte rface 0, class 0) [ 1249.600258] em28xx: Video interface 0 found: isoc [ 1249.600264] em28xx: DVB interface 0 found: isoc Hmm... yet another device where we detect a DVB endpoint (which is obviously wrong)... Could you please post the output of lsusb -v -d 0ccd:0096 ? # lsusb -vvv -d 0ccd:0096 Bus 005 Device 028: ID 0ccd:0096 TerraTec Electronic GmbH Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0096 bcdDevice1.00 iManufacturer 2 iProduct1 iSerial 0 bNumConfigurations 1 Couldn't get configuration descriptor 0, some information will be missing Couldn't get configuration descriptor 0, some information will be missing The errors are weird. strace gives: open(/dev/bus/usb/005/028, O_RDONLY) = -1 ENOENT (No such file or directory) open(/dev/bus/usb/005/028, O_RDONLY) = -1 ENOENT (No such file or directory) # ls /dev/bus/usb/005/ 001 003 013 -- 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: Terratec Grabby hwrev 2
On Wed, 27 Mar 2013 19:57:49 +0200 Timo Teras timo.te...@iki.fi wrote: The errors are weird. strace gives: open(/dev/bus/usb/005/028, O_RDONLY) = -1 ENOENT (No such file or directory) open(/dev/bus/usb/005/028, O_RDONLY) = -1 ENOENT (No such file or directory) # ls /dev/bus/usb/005/ 001 003 013 Seems something fishy in my mdev setup. Here's the full output: # lsusb -vvv -d 0ccd:0096 Bus 005 Device 029: ID 0ccd:0096 TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0096 bcdDevice1.00 iManufacturer 2 TerraTec Electronic GmbH iProduct1 TerraTec Grabby iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 2 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7
Re: Terratec Grabby hwrev 2
On Mon, 25 Mar 2013 21:12:38 +0200 Timo Teras timo.te...@iki.fi wrote: On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:48:20 +0200 Timo Teras timo.te...@iki.fi escreveu: On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Weird. Except for an additional delay, those debug stuff shouldn't be changing the driver's behavior. Are those results consistent? There are some known problems with a few em28xx devices that, from time to time, aren't able to read data from the eeprom. On such devices, it is a hardware issue. Actually it seems consistent that: 1. load em28xx - attach USB - fail 2. attach USB - load em28xx - success Sounds like if the driver is loaded, it tries to access eeprom while it's still initializing or something like that. Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. Ok, thanks! Seems that USBPcap needs compiling and TESTSIGNING enabled - so I'd rather avoid it. I did get etl format windows captures via logman start usbtrace. Can you read those, or know anyway to convert them to text / something wireshark reads? Seems not easily. And all the nice looking USB tracers cost money to get anything out. I did manage to get decent traces with USBlyzer evaluation version. The output is at: http://dev.alpinelinux.org/~tteras/grabby-rev2-init.html I had to add by hand the 'R xx' notes (Setup Packet wIndex) in Request Details for VendorDevice requests. Thus they are present only in the ones close to when the Isoch transfer starts. If you need more of them, let me know and I can paste them. Alternatively, I can dump the USBlyzer format capture somewhere if you have a windows with the program installed. The sequence to create capture was: 1. Attach USB device 2. Start capture 3. Start program that uses initiates video capture 4. Stop program 5. Stop capture So it should contain everything done at stream on time. - Timo -- 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
Terratec Grabby hwrev 2
I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1249.600246] em28xx: New device TerraTec Electronic GmbH TerraTec Grabby @ 480 Mbps (0ccd:0096, inte rface 0, class 0) [ 1249.600258] em28xx: Video interface 0 found: isoc [ 1249.600264] em28xx: DVB interface 0 found: isoc [ 1249.600443] em28xx: chip ID is em2860 [ 1249.715053] em2860 #0: i2c eeprom 00: 1a eb 67 95 cd 0c 96 00 50 00 11 03 9c 20 6a 32 [ 1249.715084] em2860 #0: i2c eeprom 10: 00 00 06 57 0e 02 00 00 00 00 00 00 00 00 00 00 [ 1249.715110] em2860 #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [ 1249.715136] em2860 #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 1249.715161] em2860 #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715186] em2860 #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715211] em2860 #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 32 03 54 00 65 00 [ 1249.715235] em2860 #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [ 1249.715261] em2860 #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [ 1249.715286] em2860 #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 20 03 54 00 [ 1249.715311] em2860 #0: i2c eeprom a0: 65 00 72 00 72 00 61 00 54 00 65 00 63 00 20 00 [ 1249.715336] em2860 #0: i2c eeprom b0: 47 00 72 00 61 00 62 00 62 00 79 00 48 00 00 00 [ 1249.715361] em2860 #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715385] em2860 #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715410] em2860 #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715435] em2860 #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1249.715464] em2860 #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xd3498090 [ 1249.715470] em2860 #0: EEPROM info: [ 1249.715475] em2860 #0: AC97 audio (5 sample rates) [ 1249.715480] em2860 #0: 500mA max power [ 1249.715487] em2860 #0: Table at 0x06, strings=0x209c, 0x326a, 0x [ 1249.715495] em2860 #0: Identified as Terratec Grabby (card=67) [ 1250.058076] em2860 #0: Config register raw data: 0x50 [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 [ 1250.086822] em2860 #0: Unknown AC97 audio processor detected! [ 1251.116646] em2860 #0: v4l2 driver version 0.1.3 [ 1251.891145] em2860 #0: V4L2 video device registered as video0 [ 1251.891155] em2860 #0: V4L2 VBI device registered as vbi0 [ 1251.891161] em2860 #0: analog set to isoc mode. [ 1251.891167] em2860 #0: dvb set to isoc mode. [ 1251.910649] usbcore: registered new interface driver em28xx Any suggestions how to debug/fix this? Thanks, Timo -- 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: Terratec Grabby hwrev 2
On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. - Timo -- 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: Terratec Grabby hwrev 2
On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:48:20 +0200 Timo Teras timo.te...@iki.fi escreveu: On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Mon, 25 Mar 2013 19:08:46 +0200 Timo Teras timo.te...@iki.fi escreveu: I just bought a Terratec Grabby hardware revision 2 in hopes that it would work on my linux box. But alas, I got only sound working. It seems that analog video picture grabbing does not work. I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and 3.9.0-rc4 (vanilla). And all fail the same way - no video data received. The USB ID is same as on the revision 1 board: Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH And it is properly detected as Grabby. It seems that the videobuf2 changes for 3.9.0-rc4 resulted in better debug logging, and it implies that the application (ffmpeg 1.1.4) is behaving well: all buffers are allocated, mmapped, queued, streamon called. But no data is received from the dongle. I also tested mencoder and it fails in similar manner. Dmesg (on 3.9.0-rc4) tells after module load the following: [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 [ 1250.086814] em2860 #0: AC97 features = 0x60f1 That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I suspect that the GPIOs for this device are different than on version 1. Yes, I just noticed this now too. It seems something went wrong when loading em28xx with a bunch of debug logging enabled. On normal load it returns instead: [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 [ 12.463650] em2860 #0: AC97 features = 0x6a90 [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected Weird. Except for an additional delay, those debug stuff shouldn't be changing the driver's behavior. Are those results consistent? There are some known problems with a few em28xx devices that, from time to time, aren't able to read data from the eeprom. On such devices, it is a hardware issue. Actually it seems consistent that: 1. load em28xx - attach USB - fail 2. attach USB - load em28xx - success Sounds like if the driver is loaded, it tries to access eeprom while it's still initializing or something like that. Any suggestions how to debug/fix this? The better is to run the original driver at a recent version of KVM with USB port forward enabled, and capture the USB logs. There are some pages at LinuxTV wiki explaining how to do it. Oh, ok. Seems Wireshark/USBPcap might be better option for me as I don't have KVMed Windows install handy. Will try to get traces from it. Ok, thanks! Seems that USBPcap needs compiling and TESTSIGNING enabled - so I'd rather avoid it. I did get etl format windows captures via logman start usbtrace. Can you read those, or know anyway to convert them to text / something wireshark reads? Native .etl and the .etl converted to .cap do not work in wireshark: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6694 - Timo -- 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