Re: Support for Empia 2980 video/audio capture chip set

[Keith Lawson <keith.lawson@libertas-tech.com>]

On Sun, Mar 02, 2014 at 06:54:41PM +0100, Frank Schäfer wrote:
> 
> Am 27.02.2014 02:47, schrieb Keith Lawson:
> > On Mon, Feb 24, 2014 at 06:38:59PM +0100, Frank Schäfer wrote:
> >> Am 06.02.2014 13:57, schrieb Keith Lawson:
> >>> On Mon, Jan 20, 2014 at 09:08:25PM +0100, Frank Schäfer wrote:
> >>>> On 17.01.2014 01:11, Keith Lawson wrote:
> >>>>> On Wed, Jan 15, 2014 at 10:37:44PM +0100, Frank Schäfer wrote:
> >>>>>> Am 14.01.2014 01:48, schrieb Keith Lawson:
> >>>>>>> On 2014-01-12 11:56, Frank Schäfer wrote:
> >>>>>>>
> >>>>>>>> On 09.01.2014 02:02, Keith Lawson wrote:
> >>>>>>>>
> >>>>>>>>> Hello, I sent the following message to the linux-usb mailing list
> >>>>>>>>> and they suggested I try here. I'm trying to get a "Dazzle Video
> >>>>>>>>> Capture USB V1.0" video capture card working on a Linux device but
> >>>>>>>>> it doesn't
> >>>>>>>>> look like the chip set is supported yet. I believe this card is the
> >>>>>>>>> next version of the Pinnacle VC100 capture card that worked with the
> >>>>>>>>> em28xx kernel module. The hardware vendor that sold the card says that
> >>>>>>>>> this device has an Empia 2980 chip set in it so I'm inquiring about
> >>>>>>>>> support for that chip set. I'm just wondering about the best
> >>>>>>>>> approach for getting the new chip supported in the kernel. Is this
> >>>>>>>>> something the
> >>>>>>>>> em28xx maintainers would naturally address in time or can I assist
> >>>>>>>>> in getting this into the kernel? Here's dmesg from the Debian box
> >>>>>>>>> I'm working on: [ 3198.920619] usb 3-1: new high-speed USB device
> >>>>>>>>> number 5
> >>>>>>>>> usingxhci_hcd [ 3198.939394] usb 3-1: New USB device found,
> >>>>>>>>> idVendor=1b80,idProduct=e60a [ 3198.939399] usb 3-1: New USB device
> >>>>>>>>> strings: Mfr=0, Product=1,SerialNumber=2 [ 3198.939403] usb 3-1:
> >>>>>>>>> Product: Dazzle
> >>>>>>>>> Video Capture USB Audio Device [ 3198.939405] usb 3-1: SerialNumber:
> >>>>>>>>> 0 l440:~$ uname -a Linux l440 3.10-3-amd64 #1 SMP Debian 3.10.11-1
> >>>>>>>>> (2013-09-10) x86_64 GNU/Linux If this isn't the appropriate list to ask
> >>>>>>>>> this question please point me in the right direction. Thanks, Keith
> >>>>>>>> The em28xx is indeed the dedicated driver for this device, but it's hard
> >>>>>>>> to say how much work would be necessary to add support for it.
> >>>>>>>> We currently don't support any em29xx chip yet, but in theory it is just
> >>>>>>>> an extended em28xx device.
> >>>>>>>> Whatever that means when it comes to the low level stuff... ;)
> >>>>>>>>
> >>>>>>> What's the best route to get support for this chip added then? Should
> >>>>>>> I start working on a patch myself or will this just happen during the
> >>>>>>> course of development of the em28xx module? I'm a developer but
> >>>>>>> haven't done any kernel hacking so this would likely be a steep
> >>>>>>> learning curve for me.
> >>>>>> Can you create USB-Traces of the Windows driver and send us the output
> >>>>>> of "lsusb -v -d 1b80:e60a" for this device ?
> >>>>>> That will give us a hint how much work will be needed.
> >>>>> For the USB-trace will the Win7 logman output do or is there a Win7 64-bit utility like usbsnoop I should use?
> >>>> AFAIK the logman output doesn't contain any transferred data.
> >>>> SniffUSB would be preferred, but AFAIK it doesn't work with Win 7.
> >>>> You may also want to try USBPcap (http://desowin.org/usbpcap/), but
> >>>> I don't know if it runs on the 64bit version of Win 7.
> >>>> There are also various commercial USB-Sniffers and some of them are
> >>>> providing a free trial period/version.
> >>>> In any case we need a readable (text) sniffing output.
> >>> Thanks for the pointer. I used USBPcap and exported text out of wireshark. 
> >>>
> >>> Here's the capture of connecting the device: 
> >>>
> >>> https://www.libertas-tech.com/dazzle_usb_connect.txt
> >>>
> >>> Here's a capture of the device recording a 1 minute video. This one is almost 700 meg so you probably don't want to try and open it in a browser: 
> >>>
> >>> https://www.libertas-tech.com/dazzle_recording_video.txt 
> >>>
> >>> I can arrange to get one of these devices in the hands of a developer if that would help too. 
> >> Sorry for the delay, I'm currently burried under lots other stuff...
> > No worries. I know that feeling all too well. 
> >
> >> I haven't finished evaluating these logs yet, but so far I can say that
> >> there's a lot of known stuff but also much new/unknown stuff.
> >> Which capturing settings (resolution, video format, ...) did you use for
> >> these logs ?
> > Someone else did the capture for me since I didn't have a Windows box it would work on. He had it connected to a video camera but didn't have an audio connection so there's no sound.
> >
> > Here's the settings from the Pinnical software.
> >
> > The properties of the video are:
> >
> > Codec                   IPB MPEG-2 MP@ML 4:2:0
> > Bitrate                  8000 kBit/s
> > Duration              00:00:05.10
> > Color Depth        16 Bit
> > Frame Aspect    4:3
> > Alpha                    No
> > Dimensions        720 x 480 px
> > Pixel Aspect       0.89
> > Framestart          0
> > Frames                 29.97 FPS
> > Interlacing           Top Field First
> 
> Hmm... looking at the logs, I would have expected 720x240 + YUV422...
> 
> 
> > The properties of the audio are:
> > Codec                   MP2
> > Bitrate                  224kBit/s
> > Duration              00:00:5.17
> > Sample Rate       48 kHz
> > Channels             Stereo
> > Resolution          16 Bit
> > Sample Type      Stereo
> > Format                 PCM
> >
> > When I click on 'Import' there aren't a tone of settings:
> >
> > Dazzle Video Capture is set to 'Video Composite', 4:3, and NTSC
> >
> > Mode is set to 'Scene detection ON'
> >
> >
> >> Does the device consist of any other chips (AC97, demodulator, ...) ?
> >>
> > Not that I see. There's a couple smaller chips on the device. I uploaded pictures here: 
> >
> > https://www.libertas-tech.com//dazzle1.jpg
> > https://www.libertas-tech.com//dazzle2.jpg
> 
> Ok, thanks, I suspected that. :/
> It seems like the em298x has a built-in demodulator (and likely also an
> audio codec).
> I can see lots of reads/writes to a "special" address in the log.
> 
> 
> Ok, here is a summary of what needs to be done to support this device
> and what is already more or less in place:
> 
> Should work out of the box or can be made work with minor changes:
> 1.) chip type detection (can be added easily with a small patch)
> 2.) eeprom access
> 3.) i2c bus access
> 4.) capturing configuration and start/stop (bridge part)
> 5.) frame processing (seems to be at least very similar to the one used
> by the other em27xx/em28xx, I can see the same header type)
> 6.) audio part
> 
> ToDo:
> 1.) figure out the meaning of the USB endpoints and extend the current
> logic to handle them properly
> 2.) add support for the built-in demodulator (an access routine is easy
> to add, but the registers meaning/setup is completely unknown)
> 3.) figure out the meaning of some new/unknown bridge registers (0x2e,
> 0x38, 0x44, 0x4f, 0xb0-0xb8), xclk (reg 0x0f) is set to an unknown frequency
> 
> 1.) and 3.) could probably be achieved with a good piece of reverse
> engineering work and some dirty hacks.
> But 2.) is hardly possible without the datasheet of the em298x. :(
> 
> Any chance to get access to the datasheet ? :-)

Thanks for the detailed explanation. My client is following up with their hardware vendor to see if they can get a copy of the data sheet and I emailed the hardware manufacturer myself. We'll see if we get a response. 

> 
> Regards,
> Frank
> 
> 
> >> Regards,
> >> Frank
> >>
> >>>>> Here's the lsusb output:
> >>>> ...
> >>>>
> >>>>>     Interface Descriptor:
> >>>>>       bLength                 9
> >>>>>       bDescriptorType         4
> >>>>>       bInterfaceNumber        0
> >>>>>       bAlternateSetting       7
> >>>>>       bNumEndpoints           4
> >>>>>       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     0x03ac  1x 940 bytes
> >>>>>         bInterval               1
> >>>>>       Endpoint Descriptor:
> >>>>>         bLength                 7
> >>>>>         bDescriptorType         5
> >>>>>         bEndpointAddress     0x8a  EP 10 IN
> >>>>>         bmAttributes            2
> >>>>>           Transfer Type            Bulk
> >>>>>           Synch Type               None
> >>>>>           Usage Type               Data
> >>>>>         wMaxPacketSize     0x0200  1x 512 bytes
> >>>>>         bInterval               0
> >>>> This endpoint configuration is different from the Empia devices
> >>>> we've seen so far.
> >>>> We have never seen any devices using endpoint address 0x8a and
> >>>> endpoint 0x84 looks strange.
> >>>> It's hard to say what they are used for.
> >>>> The current em28xx driver will assume 0x84 is used for DVB, but that
> >>>> makes no sense for this device.
> >>>>
> >>>> Regards,
> >>>> Frank
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html