Re: Terratec Grabby hwrev 2

[Tomasz Moń]

On Mon, Mar 25, 2013 at 8:12 PM, Timo Teras timo.te...@iki.fi wrote:

 Seems that USBPcap needs compiling and TESTSIGNING enabled - so I'd
 rather avoid it.

Since USBPcap 1.0.0.3 release there is digitally signed driver and
installer available.
--
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

[Jon Arne Jørgensen]

On Fri, May 03, 2013 at 08:47:55AM +0300, Timo Teras wrote:
 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,

Register 0x02 is overridden when saa711x_s_routing is
called to select input, so the value of that register in this table shouldn't
make any difference :)

 + 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, 

Re: Terratec Grabby hwrev 2

[Ezequiel Garcia]

Hi Jon,

On Fri, May 03, 2013 at 11:13:17AM +0200, Jon Arne Jørgensen wrote:
[...]
 
 I've tested the changes, and it doesn't seem to break/change the smi2021 
 driver.
 I'll append this to the pending saa7115 patch and ask Ezequiel Garcia to check
 that the change doesn't break the stk1160 driver.
 

Wow, this gm7113c are starting to appear everywhere.

Will you submit a v5 including this? In that case please drop my Tested-by
from the 3/3 patch since I need to re-test that again.

Thanks,
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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

[Timo Teras]

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

[Timo Teras]

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

[Timo Teras]

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

[Jon Arne Jørgensen]

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

 - 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
--
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

[Timo Teras]

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

[Frank Schäfer]

Am 03.04.2013 10:27, schrieb Timo Teras:
 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.

The em2860 supports VBI, so VBI mode is used.
You can force the normal mode with module parameter disable_vbi=1

 [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.

Sure, int this case it's up to libv4l2 to select an approriate driver
source format for the conversion.
But I doubt lib4vl2 will select one of the 8 bit formats when the the
destination format is a 16 bit format. ;)

 I'm also getting a usable image with the 8 

Re: Terratec Grabby hwrev 2

[Timo Teras]

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

[Frank Schäfer]

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.

 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.

 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 ? ;)

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.

 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...

 EM28XX_R1E_CWIDTH   0xB4
 EM28XX_R1F_CHEIGHT  0x48 (We set 0x8f, or 0x90)

Are you sure that 0x48 is used for PAL ? Which resolution does the
Windows driver claim too use ?
All USB-logs from the various devices I've seen so far match what we do
in the driver (0x90).

 EM28XX_R1B_OFLOW0x00

 (Tuner and AC97 config takes place here)

 EM28XX_R0E_AUDIOSRC 0x8f
 EM28XX_R21_YOFFSET  0x08 (We set 0x10)

This is the brightness value...

 EM28XX_R20_YGAIN0x10
 EM28XX_R22_UVGAIN   0x10
 EM28XX_R14_GAMMA0x32 (We set 0x20)
 EM28XX_R25_SHARPNESS0x02 (We set 0x00)

... and these are the Gamma and Sharpness values.

The Windows driver uses different image quality settings for different
devices, while our em28xx driver uses a single (common) set of values.

 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 

Re: Terratec Grabby hwrev 2

[Frank Schäfer]

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.

 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.

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.


 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.

 --

 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)

You should talk to the saa7115 maintainer about that.

  3. em28xx crop height/vstart to divided by 2 in interlaced mode
  4. (optionally) em28xx outfmt should default to YUYV422

Both isn't necessary (as explained above).
What definitely needs to be fixed in the em28xx driver are the
non-16bit-formats.

Regards,
Frank

 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

--
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

[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)
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

[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.

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: Terratec Grabby hwrev 2

[Timo Teras]

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

[Mauro Carvalho Chehab]

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.

 
 - Timo


-- 

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

Re: Terratec Grabby hwrev 2

[Timo Teras]

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

[Timo Teras]

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

[Mauro Carvalho Chehab]

Em Thu, 28 Mar 2013 15:35:56 +0200
Timo Teras timo.te...@iki.fi escreveu:

 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.

Well, I suspect that you'll need to open the box and see what's there.

Are you sure that you've initiated the needed GPIO settings before
start writing data to it?

 
 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

The driver supports several chipset variants, by reading the ID
data from it. If the autodetection code didn't work, it may be
sending commands to the wrong variation.

Also, if this is a clone, it may require some different setups
for it to work, either at saa711x driver or less likely at em28xx.

 
 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.
 
 - Timo


-- 

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

Re: Terratec Grabby hwrev 2

[Timo Teras]

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

[Frank Schäfer]

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 ?

Regards,
Frank


 [ 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

--
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

[Timo Teras]

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

[Timo Teras]

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

[Frank Schäfer]

Am 27.03.2013 19:04, schrieb Timo Teras:
 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

Re: Terratec Grabby hwrev 2

[Timo Teras]

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

[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
[ 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

[Mauro Carvalho Chehab]

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:
  
 [ 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

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.

 [ 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?

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.

Regards,
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

Re: Terratec Grabby hwrev 2

[Timo Teras]

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

[Mauro Carvalho Chehab]

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.

 
   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!

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

Re: Terratec Grabby hwrev 2

[Timo Teras]

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