On Mon, 25 Mar 2013 15:32:20 -0300 Mauro Carvalho Chehab <mche...@redhat.com> wrote:
> Em Mon, 25 Mar 2013 19:48:20 +0200 > Timo Teras <timo.te...@iki.fi> escreveu: > > > On Mon, 25 Mar 2013 14:36:47 -0300 > > Mauro Carvalho Chehab <mche...@redhat.com> wrote: > > > > > Em Mon, 25 Mar 2013 19:08:46 +0200 > > > Timo Teras <timo.te...@iki.fi> escreveu: > > > > > > > I just bought a Terratec Grabby hardware revision 2 in hopes > > > > that it would work on my linux box. > > > > > > > > But alas, I got only sound working. It seems that analog video > > > > picture grabbing does not work. > > > > > > > > I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2-grsec and > > > > 3.9.0-rc4 (vanilla). And all fail the same way - no video data > > > > received. > > > > > > > > The USB ID is same as on the revision 1 board: > > > > Bus 005 Device 002: ID 0ccd:0096 TerraTec Electronic GmbH > > > > > > > > And it is properly detected as Grabby. > > > > > > > > It seems that the videobuf2 changes for 3.9.0-rc4 resulted in > > > > better debug logging, and it implies that the application > > > > (ffmpeg 1.1.4) is behaving well: all buffers are allocated, > > > > mmapped, queued, streamon called. But no data is received from > > > > the dongle. I also tested mencoder and it fails in similar > > > > manner. > > > > > > > > Dmesg (on 3.9.0-rc4) tells after module load the following: > > > > > > > > [ 1250.076845] em2860 #0: AC97 vendor ID = 0x60f160f1 > > > > [ 1250.086814] em2860 #0: AC97 features = 0x60f1 > > > > > > That looks weird on my eyes: 3 AC97 reads returned 0x60f1. I > > > suspect that the GPIOs for this device are different than on > > > version 1. > > > > Yes, I just noticed this now too. It seems something went wrong when > > loading em28xx with a bunch of debug logging enabled. On normal > > load it returns instead: > > > > [ 12.453631] em2860 #0: AC97 vendor ID = 0x83847650 > > [ 12.463650] em2860 #0: AC97 features = 0x6a90 > > [ 12.463658] em2860 #0: Empia 202 AC97 audio processor detected > > Weird. Except for an additional delay, those debug stuff shouldn't be > changing the driver's behavior. > > Are those results consistent? There are some known problems with a few > em28xx devices that, from time to time, aren't able to read data from > the eeprom. On such devices, it is a hardware issue. Actually it seems consistent that: 1. load em28xx -> attach USB -> fail 2. attach USB -> load em28xx -> success Sounds like if the driver is loaded, it tries to access eeprom while it's still initializing or something like that. > > > > Any suggestions how to debug/fix this? > > > > > > The better is to run the original driver at a recent version of > > > KVM with USB port forward enabled, and capture the USB logs. > > > There are some pages at LinuxTV wiki explaining how to do it. > > > > Oh, ok. Seems Wireshark/USBPcap might be better option for me as I > > don't have KVMed Windows install handy. Will try to get traces from > > it. > > Ok, thanks! Seems that USBPcap needs compiling and TESTSIGNING enabled - so I'd rather avoid it. I did get etl format windows captures via "logman start usbtrace". Can you read those, or know anyway to convert them to text / something wireshark reads? Native .etl and the .etl converted to .cap do not work in wireshark: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6694 - Timo -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
