Terratec Grabby hwrev 2 · kernelthread

Timo Teras

author

2013-03-25 17:07 UTC #0 lore raw

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

Mauro Carvalho Chehab

2013-03-25 17:36 UTC #1 lore raw

Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <[email protected]> escreveu:

Quoted 44 lines

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

Quoted 8 lines

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

Quoted 9 lines

[ 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

Timo Teras

author

2013-03-25 17:47 UTC #2 lore raw

Quoted 24 lines · On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab <[email protected]>…

Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
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.

Quoted 7 lines

Quoted 4 lines
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

Quoted 5 lines

Quoted 1 line
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

Mauro Carvalho Chehab

2013-03-25 18:32 UTC #3 lore raw

Em Mon, 25 Mar 2013 19:48:20 +0200
Timo Teras <[email protected]> escreveu:

Quoted 35 lines

Quoted 24 lines · On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
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.
Quoted 7 lines
Quoted 4 lines
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.

Quoted 7 lines

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.

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
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

Timo Teras

author

2013-03-25 19:11 UTC #4 lore raw

Quoted 48 lines · On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab <[email protected]>…

Em Mon, 25 Mar 2013 19:48:20 +0200
Timo Teras <[email protected]> escreveu:
Quoted 37 lines
Quoted 25 lines · On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <[email protected]> escreveu:
Quoted 22 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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

Quoted 6 lines

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.

Quoted 11 lines

Quoted 9 lines
Quoted 5 lines
Quoted 1 line
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

Timo Teras

author

2013-03-26 08:20 UTC #5 lore raw

Quoted 75 lines · On Mon, 25 Mar 2013 21:12:38 +0200 Timo Teras <[email protected]> wrote:

Quoted 48 lines · On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Mon, 25 Mar 2013 19:48:20 +0200
Timo Teras <[email protected]> escreveu:
Quoted 37 lines
Quoted 25 lines · On Mon, 25 Mar 2013 14:36:47 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Mon, 25 Mar 2013 19:08:46 +0200
Timo Teras <[email protected]> escreveu:
Quoted 22 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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
Quoted 6 lines
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.
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
Quoted 1 line
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.

Quoted 8 lines

Quoted 1 line
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

Timo Teras

author

2013-03-27 14:09 UTC #6 lore raw

Quoted 1 line · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> 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

Timo Teras

author

2013-03-28 08:51 UTC #7 lore raw

Quoted 5 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:

Quoted 1 line · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.

Quoted 8 lines

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

Mauro Carvalho Chehab

2013-03-28 12:41 UTC #8 lore raw

Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:

Quoted 17 lines

Quoted 5 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 1 line · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.

Quoted 7 lines

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.

Quoted 2 lines

- Timo

Signature · 2 lines

Cheers,
Mauro

Timo Teras

author

2013-03-28 13:35 UTC #9 lore raw

Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…

Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.

Quoted 7 lines

Quoted 4 lines
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

Timo Teras

author

2013-03-28 14:54 UTC #10 lore raw

Quoted 41 lines · On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras <[email protected]> wrote:

Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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

Quoted 7 lines

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.

Quoted 2 lines

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

Jon Arne Jørgensen

2013-05-01 17:08 UTC #11 lore raw

Quoted 58 lines · Timo Teras

Quoted 41 lines · On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras <[email protected]> wrote:
Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 7 lines
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.
Quoted 2 lines
With NTSC signal:
- unable to get a lock, and the whole picture looks garbled

Quoted 7 lines

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

Quoted 5 lines

- Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Timo Teras

author

2013-05-02 07:03 UTC #12 lore raw

Quoted 67 lines · On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen <[email protected]> wrote:

Quoted 58 lines · Timo Teras
Quoted 41 lines · On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras <[email protected]> wrote:
Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 7 lines
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.
Quoted 2 lines
With NTSC signal:
- unable to get a lock, and the whole picture looks garbled
Quoted 7 lines
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

Quoted 5 lines

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

Timo Teras

author

2013-05-03 05:46 UTC #13 lore raw

Quoted 95 lines · On Thu, 2 May 2013 10:04:56 +0300 Timo Teras <[email protected]> wrote:

Quoted 67 lines · On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen <[email protected]> wrote:
Quoted 58 lines · Timo Teras
Quoted 41 lines · On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras <[email protected]> wrote:
Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer
evaluation version.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 7 lines
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.
Quoted 2 lines
With NTSC signal:
- unable to get a lock, and the whole picture looks garbled
Quoted 7 lines
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
Quoted 5 lines
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:
(quoted diff) +3 -9
-	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,

Quoted 4 lines

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.

drivers/media/i2c/saa7115.c +22 -0

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

Jon Arne Jørgensen

2013-05-03 09:10 UTC #14 lore raw

Quoted 115 lines · Timo Teras

Quoted 95 lines · On Thu, 2 May 2013 10:04:56 +0300 Timo Teras <[email protected]> wrote:
Quoted 67 lines · On Wed, 1 May 2013 19:11:53 +0200 Jon Arne Jørgensen <[email protected]> wrote:
Quoted 58 lines · Timo Teras
Quoted 41 lines · On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras <[email protected]> wrote:
Quoted 24 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 21 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer
evaluation version.
Quoted 8 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 7 lines
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.
Quoted 2 lines
With NTSC signal:
- unable to get a lock, and the whole picture looks garbled
Quoted 7 lines
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
Quoted 5 lines
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:
(quoted diff) +3 -9
-	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,
Quoted 4 lines
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.

drivers/media/i2c/saa7115.c line 455

Quoted 6 lines

drivers/media/i2c/saa7115.c +3 -0

@@ -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 :)

Quoted 26 lines

drivers/media/i2c/saa7115.c +19 -0

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

drivers/media/i2c/saa7115.c +0 -0

 	case V4L2_IDENT_SAA7111A:
 		saa711x_writeregs(sd, saa7111_init);

drivers/media/i2c/saa7115.c

Quoted 10 lines

drivers/media/i2c/saa7115.c +3 -1

 		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.

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Ezequiel Garcia

2013-05-03 11:13 UTC #15 lore raw

Hi Jon,

On Fri, May 03, 2013 at 11:13:17AM +0200, Jon Arne Jørgensen wrote:
[...]

Quoted 5 lines

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,

Signature · 3 lines

Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Mauro Carvalho Chehab

2013-03-28 15:23 UTC #16 lore raw

In reply to Timo Teras

Em Thu, 28 Mar 2013 15:35:56 +0200
Timo Teras <[email protected]> escreveu:

Quoted 29 lines

Quoted 26 lines · On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Em Thu, 28 Mar 2013 10:52:01 +0200
Timo Teras <[email protected]> escreveu:
Quoted 23 lines
Quoted 6 lines · On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras <[email protected]> wrote:
Quoted 2 lines · On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras <[email protected]> wrote:
I did manage to get decent traces with USBlyzer evaluation version.
Quoted 8 lines
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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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?

Quoted 6 lines

Sounds like the same issue as:
http://www.spinics.net/lists/linux-media/msg57926.html
Additionally noted that something is not initialized right:

Quoted 8 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

- Timo

Signature · 2 lines

Cheers,
Mauro

Timo Teras

author

2013-03-30 09:54 UTC #17 lore raw

Quoted 7 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…

Quoted 5 lines
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

Frank Schäfer

2013-04-01 17:25 UTC #18 lore raw

Am 30.03.2013 10:54, schrieb Timo Teras:

Quoted 14 lines

Quoted 6 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 5 lines
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

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 2 lines

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

Quoted 11 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Timo Teras

author

2013-04-02 05:42 UTC #19 lore raw

Quoted 23 lines · On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer…

Am 30.03.2013 10:54, schrieb Timo Teras:
Quoted 14 lines
Quoted 6 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 5 lines
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
Quoted 7 lines
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.

Quoted 4 lines

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

Quoted 8 lines

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

Quoted 7 lines

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.

Quoted 9 lines

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

Quoted 7 lines

Quoted 4 lines
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.

Quoted 7 lines

Quoted 5 lines
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 :)

Quoted 6 lines

Quoted 2 lines
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

Frank Schäfer

2013-04-02 16:38 UTC #20 lore raw

Am 02.04.2013 07:43, schrieb Timo Teras:

Quoted 34 lines

Quoted 22 lines · On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer…
Am 30.03.2013 10:54, schrieb Timo Teras:
Quoted 14 lines
Quoted 6 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 5 lines
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
Quoted 7 lines
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.
Quoted 4 lines
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:

Quoted 13 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 6 lines

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

Quoted 4 lines

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.

Quoted 37 lines

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
Quoted 7 lines
Quoted 7 lines
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.
Quoted 7 lines
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.
Quoted 9 lines
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.

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
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.

Quoted 8 lines

Quoted 6 lines
Quoted 5 lines
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

Quoted 9 lines

Quoted 6 lines
Quoted 3 lines
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

Timo Teras

author

2013-04-03 08:26 UTC #21 lore raw

Quoted 50 lines · On Tue, 02 Apr 2013 18:39:25 +0200 Frank Schäfer…

Am 02.04.2013 07:43, schrieb Timo Teras:
Quoted 35 lines
Quoted 23 lines · On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer…
Am 30.03.2013 10:54, schrieb Timo Teras:
Quoted 15 lines
Quoted 7 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 6 lines
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
Quoted 7 lines
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.
Quoted 4 lines
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:
Quoted 13 lines
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)

Quoted 3 lines

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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 16 lines

Quoted 4 lines
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)

Quoted 4 lines

    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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 9 lines

[snip]
Quoted 2 lines
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.

Quoted 7 lines

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

Quoted 5 lines

Quoted 2 lines
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

Frank Schäfer

2013-04-05 15:32 UTC #22 lore raw

Am 03.04.2013 10:27, schrieb Timo Teras:

Quoted 91 lines

Quoted 49 lines · On Tue, 02 Apr 2013 18:39:25 +0200 Frank Schäfer…
Am 02.04.2013 07:43, schrieb Timo Teras:
Quoted 35 lines
Quoted 23 lines · On Mon, 01 Apr 2013 19:26:53 +0200 Frank Schäfer…
Am 30.03.2013 10:54, schrieb Timo Teras:
Quoted 15 lines
Quoted 7 lines · On Thu, 28 Mar 2013 12:22:52 -0300 Mauro Carvalho Chehab <[email protected]>…
Quoted 6 lines
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
Quoted 7 lines
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.
Quoted 4 lines
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:
Quoted 13 lines
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)
Quoted 3 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 15 lines
Quoted 4 lines
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)
Quoted 4 lines
    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.
Quoted 3 lines
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.

Quoted 8 lines

Quoted 7 lines
Quoted 2 lines
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

Quoted 10 lines

Quoted 8 lines
[snip]
Quoted 2 lines
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. ;)

Quoted 9 lines

Quoted 9 lines
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... ;)
Quoted 2 lines
Basically, I got mostly OK picture, but areas with all-black and all-white next to each other got distorted (e.g. subtitles).

Quoted 7 lines

Quoted 2 lines
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.

Quoted 5 lines

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

Quoted 8 lines

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

Quoted 1 line

- Timo

Timo Teras

author

2013-04-29 12:25 UTC #23 lore raw

Quoted 5 lines · On Fri, 05 Apr 2013 17:33:07 +0200 Frank Schäfer…

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

Quoted 5 lines

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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 8 lines

Quoted 4 lines
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

Timo Teras

author

2013-05-03 05:49 UTC #24 lore raw

Quoted 25 lines · On Mon, 29 Apr 2013 15:26:18 +0300 Timo Teras <[email protected]> wrote:

Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
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);

Quoted 1 line

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.

drivers/media/usb/em28xx/em28xx-cards.c +13 -0

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

Tomasz Moń

2013-05-10 11:05 UTC #25 lore raw

In reply to Timo Teras

Quoted 3 lines · Timo Teras

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.

Frank Schäfer

2013-03-27 17:36 UTC #26 lore raw

In reply to Timo Teras

Am 25.03.2013 18:08, schrieb Timo Teras:

Quoted 20 lines

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.

Quoted 6 lines

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

Quoted 42 lines

[ 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Timo Teras

author

2013-03-27 17:56 UTC #27 lore raw

Quoted 24 lines · On Wed, 27 Mar 2013 18:37:26 +0100 Frank Schäfer…

Am 25.03.2013 18:08, schrieb Timo Teras:
Quoted 23 lines
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:

Quoted 8 lines

Quoted 4 lines
[ 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

Timo Teras

author

2013-03-27 18:03 UTC #28 lore raw

Quoted 7 lines · On Wed, 27 Mar 2013 19:57:49 +0200 Timo Teras <[email protected]> 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)

Frank Schäfer

2013-03-27 20:11 UTC #29 lore raw

Am 27.03.2013 19:04, schrieb Timo Teras:

Quoted 692 lines

Quoted 7 lines · On Wed, 27 Mar 2013 19:57:49 +0200 Timo Teras <[email protected]> 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

Quoted 7 lines

  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