* Terratec Grabby hwrev 2
@ 2013-03-25 17:08 Timo Teras
2013-03-25 17:36 ` Mauro Carvalho Chehab
2013-03-27 17:37 ` Frank Schäfer
0 siblings, 2 replies; 30+ messages in thread
From: Timo Teras @ 2013-03-25 17:08 UTC (permalink / raw)
To: linux-media
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, 0x0000
[ 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 17:08 Terratec Grabby hwrev 2 Timo Teras
@ 2013-03-25 17:36 ` Mauro Carvalho Chehab
2013-03-25 17:48 ` Timo Teras
2013-03-27 17:37 ` Frank Schäfer
1 sibling, 1 reply; 30+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-25 17:36 UTC (permalink / raw)
To: Timo Teras; +Cc: linux-media
Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <timo.teras@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, 0x0000
> [ 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 17:36 ` Mauro Carvalho Chehab
@ 2013-03-25 17:48 ` Timo Teras
2013-03-25 18:32 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-25 17:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
On Mon, 25 Mar 2013 14:36:47 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Mon, 25 Mar 2013 19:08:46 +0200
> Timo Teras <timo.teras@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 17:48 ` Timo Teras
@ 2013-03-25 18:32 ` Mauro Carvalho Chehab
2013-03-25 19:12 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-25 18:32 UTC (permalink / raw)
To: Timo Teras; +Cc: linux-media
Em Mon, 25 Mar 2013 19:48:20 +0200
Timo Teras <timo.teras@iki.fi> escreveu:
> On Mon, 25 Mar 2013 14:36:47 -0300
> Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>
> > Em Mon, 25 Mar 2013 19:08:46 +0200
> > Timo Teras <timo.teras@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 18:32 ` Mauro Carvalho Chehab
@ 2013-03-25 19:12 ` Timo Teras
2013-03-26 8:20 ` Timo Teras
2013-05-10 11:04 ` Tomasz Moń
0 siblings, 2 replies; 30+ messages in thread
From: Timo Teras @ 2013-03-25 19:12 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
On Mon, 25 Mar 2013 15:32:20 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Mon, 25 Mar 2013 19:48:20 +0200
> Timo Teras <timo.teras@iki.fi> escreveu:
>
> > On Mon, 25 Mar 2013 14:36:47 -0300
> > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> >
> > > Em Mon, 25 Mar 2013 19:08:46 +0200
> > > Timo Teras <timo.teras@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 19:12 ` Timo Teras
@ 2013-03-26 8:20 ` Timo Teras
2013-03-27 14:10 ` Timo Teras
2013-05-10 11:04 ` Tomasz Moń
1 sibling, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-26 8:20 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
On Mon, 25 Mar 2013 21:12:38 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Mon, 25 Mar 2013 15:32:20 -0300
> Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>
> > Em Mon, 25 Mar 2013 19:48:20 +0200
> > Timo Teras <timo.teras@iki.fi> escreveu:
> >
> > > On Mon, 25 Mar 2013 14:36:47 -0300
> > > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> > >
> > > > Em Mon, 25 Mar 2013 19:08:46 +0200
> > > > Timo Teras <timo.teras@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-26 8:20 ` Timo Teras
@ 2013-03-27 14:10 ` Timo Teras
2013-03-28 8:52 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-27 14:10 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, linux-media
On Tue, 26 Mar 2013 10:20:56 +0200
Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 17:08 Terratec Grabby hwrev 2 Timo Teras
2013-03-25 17:36 ` Mauro Carvalho Chehab
@ 2013-03-27 17:37 ` Frank Schäfer
2013-03-27 17:57 ` Timo Teras
1 sibling, 1 reply; 30+ messages in thread
From: Frank Schäfer @ 2013-03-27 17:37 UTC (permalink / raw)
To: Timo Teras, Linux Media Mailing List
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, 0x0000
> [ 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-27 17:37 ` Frank Schäfer
@ 2013-03-27 17:57 ` Timo Teras
2013-03-27 18:04 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-27 17:57 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Linux Media Mailing List
On Wed, 27 Mar 2013 18:37:26 +0100
Frank Schäfer <fschaefer.oss@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:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0ccd TerraTec Electronic GmbH
idProduct 0x0096
bcdDevice 1.00
iManufacturer 2
iProduct 1
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-27 17:57 ` Timo Teras
@ 2013-03-27 18:04 ` Timo Teras
2013-03-27 20:12 ` Frank Schäfer
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-27 18:04 UTC (permalink / raw)
To: Timo Teras; +Cc: Frank Schäfer, Linux Media Mailing List
On Wed, 27 Mar 2013 19:57:49 +0200
Timo Teras <timo.teras@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:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0ccd TerraTec Electronic GmbH
idProduct 0x0096
bcdDevice 1.00
iManufacturer 2 TerraTec Electronic GmbH
iProduct 1 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
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 2
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0ad4 2x 724 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 3
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0c00 2x 1024 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 4
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x1300 3x 768 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 5
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x135c 3x 860 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 6
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x13c4 3x 964 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 7
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 11
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 39
bInCollection 1
baInterfaceNr( 0) 2
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0603 Line Connector
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 2
bSourceID 1
bControlSize 1
bmaControls( 0) 0x03
Mute Control
Volume Control
bmaControls( 1) 0x00
iFeature 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 2
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x00c4 1x 196 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 44100
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x00b4 1x 180 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 3
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 32000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0084 1x 132 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 16000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0044 1x 68 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 5
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 1 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 8000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0024 1x 36 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-27 18:04 ` Timo Teras
@ 2013-03-27 20:12 ` Frank Schäfer
0 siblings, 0 replies; 30+ messages in thread
From: Frank Schäfer @ 2013-03-27 20:12 UTC (permalink / raw)
To: Timo Teras; +Cc: Linux Media Mailing List
Am 27.03.2013 19:04, schrieb Timo Teras:
> On Wed, 27 Mar 2013 19:57:49 +0200
> Timo Teras <timo.teras@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:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x0ccd TerraTec Electronic GmbH
> idProduct 0x0096
> bcdDevice 1.00
> iManufacturer 2 TerraTec Electronic GmbH
> iProduct 1 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
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 1
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 2
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0ad4 2x 724 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 3
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0c00 2x 1024 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 4
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x1300 3x 768 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 5
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x135c 3x 860 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 6
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x13c4 3x 964 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 7
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 255
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0001 1x 1 bytes
> bInterval 11
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x1400 3x 1024 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 0
> bInterfaceClass 1 Audio
> bInterfaceSubClass 1 Control Device
> bInterfaceProtocol 0
> iInterface 0
> AudioControl Interface Descriptor:
> bLength 9
> bDescriptorType 36
> bDescriptorSubtype 1 (HEADER)
> bcdADC 1.00
> wTotalLength 39
> bInCollection 1
> baInterfaceNr( 0) 2
> AudioControl Interface Descriptor:
> bLength 12
> bDescriptorType 36
> bDescriptorSubtype 2 (INPUT_TERMINAL)
> bTerminalID 1
> wTerminalType 0x0603 Line Connector
> bAssocTerminal 0
> bNrChannels 2
> wChannelConfig 0x0003
> Left Front (L)
> Right Front (R)
> iChannelNames 0
> iTerminal 0
> AudioControl Interface Descriptor:
> bLength 9
> bDescriptorType 36
> bDescriptorSubtype 6 (FEATURE_UNIT)
> bUnitID 2
> bSourceID 1
> bControlSize 1
> bmaControls( 0) 0x03
> Mute Control
> Volume Control
> bmaControls( 1) 0x00
> iFeature 0
> AudioControl Interface Descriptor:
> bLength 9
> bDescriptorType 36
> bDescriptorSubtype 3 (OUTPUT_TERMINAL)
> bTerminalID 3
> wTerminalType 0x0101 USB Streaming
> bAssocTerminal 0
> bSourceID 2
> iTerminal 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 0
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 1
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 48000
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x00c4 1x 196 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 2
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 44100
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x00b4 1x 180 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 3
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 32000
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0084 1x 132 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 4
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 16000
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0044 1x 68 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 5
> bNumEndpoints 1
> bInterfaceClass 1 Audio
> bInterfaceSubClass 2 Streaming
> bInterfaceProtocol 0
> iInterface 0
> AudioStreaming Interface Descriptor:
> bLength 7
> bDescriptorType 36
> bDescriptorSubtype 1 (AS_GENERAL)
> bTerminalLink 3
> bDelay 1 frames
> wFormatTag 1 PCM
> AudioStreaming Interface Descriptor:
> bLength 11
> bDescriptorType 36
> bDescriptorSubtype 2 (FORMAT_TYPE)
> bFormatType 1 (FORMAT_TYPE_I)
> bNrChannels 2
> bSubframeSize 2
> bBitResolution 16
> bSamFreqType 1 Discrete
> tSamFreq[ 0] 8000
> Endpoint Descriptor:
> bLength 9
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0024 1x 36 bytes
> bInterval 4
> bRefresh 0
> bSynchAddress 0
> AudioControl Endpoint Descriptor:
> bLength 7
> bDescriptorType 37
> bDescriptorSubtype 1 (EP_GENERAL)
> bmAttributes 0x00
> bLockDelayUnits 0 Undefined
> wLockDelay 0 Undefined
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
> Device Status: 0x0000
> (Bus Powered)
Thanks !
I've sent a patch a few minutes ago (CC'ed you) that should fix the
registering of a DVB device.
The issue addressed by this patch _should_ not be reason for the issue
you are reporting in this thread, but it's definitely worth testing if
it helps ;).
Regards,
Frank
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-27 14:10 ` Timo Teras
@ 2013-03-28 8:52 ` Timo Teras
2013-03-28 12:40 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-28 8:52 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, linux-media
On Wed, 27 Mar 2013 16:10:49 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Tue, 26 Mar 2013 10:20:56 +0200
> Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 8:52 ` Timo Teras
@ 2013-03-28 12:40 ` Mauro Carvalho Chehab
2013-03-28 13:35 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-28 12:40 UTC (permalink / raw)
To: Timo Teras; +Cc: linux-media
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <timo.teras@iki.fi> escreveu:
> On Wed, 27 Mar 2013 16:10:49 +0200
> Timo Teras <timo.teras@iki.fi> wrote:
>
> > On Tue, 26 Mar 2013 10:20:56 +0200
> > Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 12:40 ` Mauro Carvalho Chehab
@ 2013-03-28 13:35 ` Timo Teras
2013-03-28 14:54 ` Timo Teras
2013-03-28 15:22 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 30+ messages in thread
From: Timo Teras @ 2013-03-28 13:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
On Thu, 28 Mar 2013 09:40:52 -0300
Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> Em Thu, 28 Mar 2013 10:52:01 +0200
> Timo Teras <timo.teras@iki.fi> escreveu:
>
> > On Wed, 27 Mar 2013 16:10:49 +0200
> > Timo Teras <timo.teras@iki.fi> wrote:
> >
> > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 13:35 ` Timo Teras
@ 2013-03-28 14:54 ` Timo Teras
2013-05-01 17:11 ` Jon Arne Jørgensen
2013-03-28 15:22 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-28 14:54 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, linux-media
On Thu, 28 Mar 2013 15:35:56 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 28 Mar 2013 09:40:52 -0300
> Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>
> > Em Thu, 28 Mar 2013 10:52:01 +0200
> > Timo Teras <timo.teras@iki.fi> escreveu:
> >
> > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > Timo Teras <timo.teras@iki.fi> wrote:
> > >
> > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 13:35 ` Timo Teras
2013-03-28 14:54 ` Timo Teras
@ 2013-03-28 15:22 ` Mauro Carvalho Chehab
2013-03-30 9:54 ` Timo Teras
1 sibling, 1 reply; 30+ messages in thread
From: Mauro Carvalho Chehab @ 2013-03-28 15:22 UTC (permalink / raw)
To: Timo Teras; +Cc: linux-media
Em Thu, 28 Mar 2013 15:35:56 +0200
Timo Teras <timo.teras@iki.fi> escreveu:
> On Thu, 28 Mar 2013 09:40:52 -0300
> Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>
> > Em Thu, 28 Mar 2013 10:52:01 +0200
> > Timo Teras <timo.teras@iki.fi> escreveu:
> >
> > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > Timo Teras <timo.teras@iki.fi> wrote:
> > >
> > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 15:22 ` Mauro Carvalho Chehab
@ 2013-03-30 9:54 ` Timo Teras
2013-04-01 17:26 ` Frank Schäfer
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-03-30 9:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
On Thu, 28 Mar 2013 12:22:52 -0300
Mauro Carvalho Chehab <mchehab@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-30 9:54 ` Timo Teras
@ 2013-04-01 17:26 ` Frank Schäfer
2013-04-02 5:43 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Frank Schäfer @ 2013-04-01 17:26 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Am 30.03.2013 10:54, schrieb Timo Teras:
> On Thu, 28 Mar 2013 12:22:52 -0300
> Mauro Carvalho Chehab <mchehab@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-01 17:26 ` Frank Schäfer
@ 2013-04-02 5:43 ` Timo Teras
2013-04-02 16:39 ` Frank Schäfer
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-04-02 5:43 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
On Mon, 01 Apr 2013 19:26:53 +0200
Frank Schäfer <fschaefer.oss@googlemail.com> wrote:
> Am 30.03.2013 10:54, schrieb Timo Teras:
> > On Thu, 28 Mar 2013 12:22:52 -0300
> > Mauro Carvalho Chehab <mchehab@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_YGAIN 0x00
EM28XX_R22_UVGAIN 0x00
EM28XX_R06_I2C_CLK 0x40
EM28XX_R15_RGAIN 0x20
EM28XX_R16_GGAIN 0x20
EM28XX_R17_BGAIN 0x20
EM28XX_R18_ROFFSET 0x00
EM28XX_R19_GOFFSET 0x00
EM28XX_R1A_BOFFSET 0x00
EM28XX_R23_UOFFSET 0x00
EM28XX_R24_VOFFSET 0x00
EM28XX_R26_COMPR 0x00
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_OFLOW 0x00
(Tuner and AC97 config takes place here)
EM28XX_R0E_AUDIOSRC 0x8f
EM28XX_R21_YOFFSET 0x08 (We set 0x10)
EM28XX_R20_YGAIN 0x10
EM28XX_R22_UVGAIN 0x10
EM28XX_R14_GAMMA 0x32 (We set 0x20)
EM28XX_R25_SHARPNESS 0x02 (We set 0x00)
EM28XX_R26_COMPR 0x00
EM28XX_R27_OUTFMT 0x34
EM28XX_R11_VINCTRL 0x11
EM28XX_R1B_OFLOW 0x00
EM28XX_R12_VINENABLE 0x67
EM28XX_R22_UVGAIN 0x10
EM28XX_R20_YGAIN 0x10
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 14-17 in case it's not the
> > original chip (id not present)
>
> You should talk to the saa7115 maintainer about that.
get_maintainers.pl says that Mauro and this list is the place to talk
to. So here I am doing it :)
> > 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.
Yeah, seems to be the case.
- Timo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-02 5:43 ` Timo Teras
@ 2013-04-02 16:39 ` Frank Schäfer
2013-04-03 8:27 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Frank Schäfer @ 2013-04-02 16:39 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Am 02.04.2013 07:43, schrieb Timo Teras:
> On Mon, 01 Apr 2013 19:26:53 +0200
> Frank Schäfer <fschaefer.oss@googlemail.com> wrote:
>
>> Am 30.03.2013 10:54, schrieb Timo Teras:
>>> On Thu, 28 Mar 2013 12:22:52 -0300
>>> Mauro Carvalho Chehab <mchehab@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_YGAIN 0x00
> EM28XX_R22_UVGAIN 0x00
> EM28XX_R06_I2C_CLK 0x40
> EM28XX_R15_RGAIN 0x20
> EM28XX_R16_GGAIN 0x20
> EM28XX_R17_BGAIN 0x20
> EM28XX_R18_ROFFSET 0x00
> EM28XX_R19_GOFFSET 0x00
> EM28XX_R1A_BOFFSET 0x00
> EM28XX_R23_UOFFSET 0x00
> EM28XX_R24_VOFFSET 0x00
> EM28XX_R26_COMPR 0x00
> 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_OFLOW 0x00
>
> (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_YGAIN 0x10
> EM28XX_R22_UVGAIN 0x10
> EM28XX_R14_GAMMA 0x32 (We set 0x20)
> EM28XX_R25_SHARPNESS 0x02 (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_COMPR 0x00
> EM28XX_R27_OUTFMT 0x34
> EM28XX_R11_VINCTRL 0x11
> EM28XX_R1B_OFLOW 0x00
> EM28XX_R12_VINENABLE 0x67
> EM28XX_R22_UVGAIN 0x10
> EM28XX_R20_YGAIN 0x10
> 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?
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.
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 to each other got distorted (e.g. subtitles).
Could you send us a screenshot ?
Looks different with my devices...
>>> 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 14-17 in case it's not the
>>> original chip (id not present)
>> You should talk to the saa7115 maintainer about that.
> get_maintainers.pl says that Mauro and this list is the place to talk
> to. So here I am doing it :)
:)
Regards,
Frank
>
>>> 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.
> Yeah, seems to be the case.
>
> - Timo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-02 16:39 ` Frank Schäfer
@ 2013-04-03 8:27 ` Timo Teras
2013-04-05 15:33 ` Frank Schäfer
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-04-03 8:27 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
On Tue, 02 Apr 2013 18:39:25 +0200
Frank Schäfer <fschaefer.oss@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.oss@googlemail.com> wrote:
> >
> >> Am 30.03.2013 10:54, schrieb Timo Teras:
> >>> On Thu, 28 Mar 2013 12:22:52 -0300
> >>> Mauro Carvalho Chehab <mchehab@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_YGAIN 0x00
> > EM28XX_R22_UVGAIN 0x00
> > EM28XX_R06_I2C_CLK 0x40
> > EM28XX_R15_RGAIN 0x20
> > EM28XX_R16_GGAIN 0x20
> > EM28XX_R17_BGAIN 0x20
> > EM28XX_R18_ROFFSET 0x00
> > EM28XX_R19_GOFFSET 0x00
> > EM28XX_R1A_BOFFSET 0x00
> > EM28XX_R23_UOFFSET 0x00
> > EM28XX_R24_VOFFSET 0x00
> > EM28XX_R26_COMPR 0x00
> > 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 to each other got distorted (e.g. subtitles).
>
> Could you send us a screenshot ?
> Looks different with my devices...
Seems ffmpeg by default wants yuv420p, and libv4l2 does some
conversions automatically to get there. The relevant grab is:
http://dev.alpinelinux.org/~tteras/image-yuv420p.jpg
You can see the red/blue pixels with subtitles. There's also some
quality loss on other sharp edges, like the edge of the white shirt.
Using --pix_fmt rgb24 seems to result in similar issues.
This is the same (paused image from DVD player) grabbed again with
--pix_fmt yuyv422: http://dev.alpinelinux.org/~tteras/image-yuyv422.jpg
which nice.
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.
- Timo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-03 8:27 ` Timo Teras
@ 2013-04-05 15:33 ` Frank Schäfer
2013-04-29 12:26 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Frank Schäfer @ 2013-04-05 15:33 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Am 03.04.2013 10:27, schrieb Timo Teras:
> On Tue, 02 Apr 2013 18:39:25 +0200
> Frank Schäfer <fschaefer.oss@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.oss@googlemail.com> wrote:
>>>
>>>> Am 30.03.2013 10:54, schrieb Timo Teras:
>>>>> On Thu, 28 Mar 2013 12:22:52 -0300
>>>>> Mauro Carvalho Chehab <mchehab@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_YGAIN 0x00
>>> EM28XX_R22_UVGAIN 0x00
>>> EM28XX_R06_I2C_CLK 0x40
>>> EM28XX_R15_RGAIN 0x20
>>> EM28XX_R16_GGAIN 0x20
>>> EM28XX_R17_BGAIN 0x20
>>> EM28XX_R18_ROFFSET 0x00
>>> EM28XX_R19_GOFFSET 0x00
>>> EM28XX_R1A_BOFFSET 0x00
>>> EM28XX_R23_UOFFSET 0x00
>>> EM28XX_R24_VOFFSET 0x00
>>> EM28XX_R26_COMPR 0x00
>>> 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 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 to each other got distorted (e.g. subtitles).
>> Could you send us a screenshot ?
>> Looks different with my devices...
> Seems ffmpeg by default wants yuv420p, and libv4l2 does some
> conversions automatically to get there. The relevant grab is:
> http://dev.alpinelinux.org/~tteras/image-yuv420p.jpg
> You can see the red/blue pixels with subtitles. There's also some
> quality loss on other sharp edges, like the edge of the white shirt.
Yeah, looks the same with my devices.
> Using --pix_fmt rgb24 seems to result in similar issues.
>
> This is the same (paused image from DVD player) grabbed again with
> --pix_fmt yuyv422: http://dev.alpinelinux.org/~tteras/image-yuyv422.jpg
> which nice.
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... :(
> 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 ?
Regards,
Frank
> - Timo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-05 15:33 ` Frank Schäfer
@ 2013-04-29 12:26 ` Timo Teras
2013-05-03 5:50 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-04-29 12:26 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
On Fri, 05 Apr 2013 17:33:07 +0200
Frank Schäfer <fschaefer.oss@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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-28 14:54 ` Timo Teras
@ 2013-05-01 17:11 ` Jon Arne Jørgensen
2013-05-02 7:04 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Jon Arne Jørgensen @ 2013-05-01 17:11 UTC (permalink / raw)
To: Timo Teras; +Cc: Mauro Carvalho Chehab, linux-media
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.teras@iki.fi> wrote:
>
> > On Thu, 28 Mar 2013 09:40:52 -0300
> > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> >
> > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > Timo Teras <timo.teras@iki.fi> escreveu:
> > >
> > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > >
> > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > Timo Teras <timo.teras@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 000000000000000) 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-05-01 17:11 ` Jon Arne Jørgensen
@ 2013-05-02 7:04 ` Timo Teras
2013-05-03 5:47 ` Timo Teras
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-05-02 7:04 UTC (permalink / raw)
To: Jon Arne Jørgensen; +Cc: Mauro Carvalho Chehab, linux-media
On Wed, 1 May 2013 19:11:53 +0200
Jon Arne Jørgensen <jonarne@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.teras@iki.fi> wrote:
> >
> > > On Thu, 28 Mar 2013 09:40:52 -0300
> > > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> > >
> > > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > > Timo Teras <timo.teras@iki.fi> escreveu:
> > > >
> > > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > > >
> > > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > > Timo Teras <timo.teras@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 000000000000000) 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-05-02 7:04 ` Timo Teras
@ 2013-05-03 5:47 ` Timo Teras
2013-05-03 9:13 ` Jon Arne Jørgensen
0 siblings, 1 reply; 30+ messages in thread
From: Timo Teras @ 2013-05-03 5:47 UTC (permalink / raw)
To: Timo Teras; +Cc: Jon Arne Jørgensen, Mauro Carvalho Chehab, linux-media
On Thu, 2 May 2013 10:04:56 +0300
Timo Teras <timo.teras@iki.fi> wrote:
> On Wed, 1 May 2013 19:11:53 +0200
> Jon Arne Jørgensen <jonarne@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.teras@iki.fi> wrote:
> > >
> > > > On Thu, 28 Mar 2013 09:40:52 -0300
> > > > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> > > >
> > > > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > > > Timo Teras <timo.teras@iki.fi> escreveu:
> > > > >
> > > > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > > > >
> > > > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > > > Timo Teras <timo.teras@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 000000000000000)
> > > > > > > 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 V4L2_IDENT_SAA7111A:
saa711x_writeregs(sd, saa7111_init);
break;
- case V4L2_IDENT_GM7113C:
case V4L2_IDENT_SAA7113:
saa711x_writeregs(sd, saa7113_init);
+ break;
+ case V4L2_IDENT_GM7113C:
+ saa711x_writeregs(sd, gm7113c_init);
break;
default:
state->crystal_freq = SAA7115_FREQ_32_11_MHZ;
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-04-29 12:26 ` Timo Teras
@ 2013-05-03 5:50 ` Timo Teras
0 siblings, 0 replies; 30+ messages in thread
From: Timo Teras @ 2013-05-03 5:50 UTC (permalink / raw)
To: Timo Teras
Cc: Frank Schäfer, Mauro Carvalho Chehab,
Linux Media Mailing List
On Mon, 29 Apr 2013 15:26:18 +0300
Timo Teras <timo.teras@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);
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-05-03 5:47 ` Timo Teras
@ 2013-05-03 9:13 ` Jon Arne Jørgensen
2013-05-03 11:12 ` Ezequiel Garcia
0 siblings, 1 reply; 30+ messages in thread
From: Jon Arne Jørgensen @ 2013-05-03 9:13 UTC (permalink / raw)
To: Timo Teras
Cc: Jon Arne Jørgensen, Mauro Carvalho Chehab, linux-media,
Ezequiel Garcia
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.teras@iki.fi> wrote:
>
> > On Wed, 1 May 2013 19:11:53 +0200
> > Jon Arne Jørgensen <jonarne@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.teras@iki.fi> wrote:
> > > >
> > > > > On Thu, 28 Mar 2013 09:40:52 -0300
> > > > > Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> > > > >
> > > > > > Em Thu, 28 Mar 2013 10:52:01 +0200
> > > > > > Timo Teras <timo.teras@iki.fi> escreveu:
> > > > > >
> > > > > > > On Wed, 27 Mar 2013 16:10:49 +0200
> > > > > > > Timo Teras <timo.teras@iki.fi> wrote:
> > > > > > >
> > > > > > > > On Tue, 26 Mar 2013 10:20:56 +0200
> > > > > > > > Timo Teras <timo.teras@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 000000000000000)
> > > > > > > > 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, 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 V4L2_IDENT_SAA7111A:
> saa711x_writeregs(sd, saa7111_init);
> break;
> - case V4L2_IDENT_GM7113C:
> case V4L2_IDENT_SAA7113:
> saa711x_writeregs(sd, saa7113_init);
> + break;
> + case V4L2_IDENT_GM7113C:
> + saa711x_writeregs(sd, gm7113c_init);
> break;
> default:
> state->crystal_freq = SAA7115_FREQ_32_11_MHZ;
>
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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-05-03 9:13 ` Jon Arne Jørgensen
@ 2013-05-03 11:12 ` Ezequiel Garcia
0 siblings, 0 replies; 30+ messages in thread
From: Ezequiel Garcia @ 2013-05-03 11:12 UTC (permalink / raw)
To: Jon Arne Jørgensen; +Cc: Timo Teras, Mauro Carvalho Chehab, linux-media
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Terratec Grabby hwrev 2
2013-03-25 19:12 ` Timo Teras
2013-03-26 8:20 ` Timo Teras
@ 2013-05-10 11:04 ` Tomasz Moń
1 sibling, 0 replies; 30+ messages in thread
From: Tomasz Moń @ 2013-05-10 11:04 UTC (permalink / raw)
To: linux-media
On Mon, Mar 25, 2013 at 8:12 PM, Timo Teras <timo.teras@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.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2013-05-10 11:05 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-25 17:08 Terratec Grabby hwrev 2 Timo Teras
2013-03-25 17:36 ` Mauro Carvalho Chehab
2013-03-25 17:48 ` Timo Teras
2013-03-25 18:32 ` Mauro Carvalho Chehab
2013-03-25 19:12 ` Timo Teras
2013-03-26 8:20 ` Timo Teras
2013-03-27 14:10 ` Timo Teras
2013-03-28 8:52 ` Timo Teras
2013-03-28 12:40 ` Mauro Carvalho Chehab
2013-03-28 13:35 ` Timo Teras
2013-03-28 14:54 ` Timo Teras
2013-05-01 17:11 ` Jon Arne Jørgensen
2013-05-02 7:04 ` Timo Teras
2013-05-03 5:47 ` Timo Teras
2013-05-03 9:13 ` Jon Arne Jørgensen
2013-05-03 11:12 ` Ezequiel Garcia
2013-03-28 15:22 ` Mauro Carvalho Chehab
2013-03-30 9:54 ` Timo Teras
2013-04-01 17:26 ` Frank Schäfer
2013-04-02 5:43 ` Timo Teras
2013-04-02 16:39 ` Frank Schäfer
2013-04-03 8:27 ` Timo Teras
2013-04-05 15:33 ` Frank Schäfer
2013-04-29 12:26 ` Timo Teras
2013-05-03 5:50 ` Timo Teras
2013-05-10 11:04 ` Tomasz Moń
2013-03-27 17:37 ` Frank Schäfer
2013-03-27 17:57 ` Timo Teras
2013-03-27 18:04 ` Timo Teras
2013-03-27 20:12 ` Frank Schäfer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).