* Support for Empia 2980 video/audio capture chip set @ 2014-01-09 1:02 Keith Lawson 2014-01-12 16:56 ` Frank Schäfer 0 siblings, 1 reply; 12+ messages in thread From: Keith Lawson @ 2014-01-09 1:02 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-09 1:02 Support for Empia 2980 video/audio capture chip set Keith Lawson @ 2014-01-12 16:56 ` Frank Schäfer 2014-01-14 0:48 ` Keith Lawson 0 siblings, 1 reply; 12+ messages in thread From: Frank Schäfer @ 2014-01-12 16:56 UTC (permalink / raw) To: keith.lawson, linux-media 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... ;) Regards, Frank ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-12 16:56 ` Frank Schäfer @ 2014-01-14 0:48 ` Keith Lawson 2014-01-15 21:37 ` Frank Schäfer 0 siblings, 1 reply; 12+ messages in thread From: Keith Lawson @ 2014-01-14 0:48 UTC (permalink / raw) To: Frank Schäfer; +Cc: linux-media, linux-media-owner 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. > 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 [1] Links: ------ [1] http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-14 0:48 ` Keith Lawson @ 2014-01-15 21:37 ` Frank Schäfer 2014-01-17 0:11 ` Keith Lawson 0 siblings, 1 reply; 12+ messages in thread From: Frank Schäfer @ 2014-01-15 21:37 UTC (permalink / raw) To: keith.lawson; +Cc: linux-media, linux-media-owner 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. Regards, Frank ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-15 21:37 ` Frank Schäfer @ 2014-01-17 0:11 ` Keith Lawson 2014-01-20 20:08 ` Frank Schäfer 0 siblings, 1 reply; 12+ messages in thread From: Keith Lawson @ 2014-01-17 0:11 UTC (permalink / raw) To: Frank Schäfer; +Cc: linux-media, linux-media-owner 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? Here's the lsusb output: Bus 001 Device 002: ID 1b80:e60a Afatech Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1b80 Afatech idProduct 0xe60a bcdDevice 1.00 iManufacturer 0 iProduct 1 iSerial 2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 406 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 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 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 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 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 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 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 2 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 0x0ad0 2x 720 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 3 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 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 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 4 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 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 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 5 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 0x1380 3x 896 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 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 6 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 0x13c0 3x 960 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 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 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 40 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 0x0000 iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize 1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 bmaControls( 2) 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 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 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 > > Regards, > Frank > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-17 0:11 ` Keith Lawson @ 2014-01-20 20:08 ` Frank Schäfer 2014-02-06 12:57 ` Keith Lawson 0 siblings, 1 reply; 12+ messages in thread From: Frank Schäfer @ 2014-01-20 20:08 UTC (permalink / raw) To: keith.lawson; +Cc: Linux Media Mailing List 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. > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-01-20 20:08 ` Frank Schäfer @ 2014-02-06 12:57 ` Keith Lawson 2014-02-24 17:38 ` Frank Schäfer 0 siblings, 1 reply; 12+ messages in thread From: Keith Lawson @ 2014-02-06 12:57 UTC (permalink / raw) To: Frank Schäfer; +Cc: Linux Media Mailing List 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. > > >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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-02-06 12:57 ` Keith Lawson @ 2014-02-24 17:38 ` Frank Schäfer 2014-02-27 1:47 ` Keith Lawson 0 siblings, 1 reply; 12+ messages in thread From: Frank Schäfer @ 2014-02-24 17:38 UTC (permalink / raw) To: Keith Lawson; +Cc: Linux Media Mailing List 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... 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 ? Does the device consist of any other chips (AC97, demodulator, ...) ? 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-02-24 17:38 ` Frank Schäfer @ 2014-02-27 1:47 ` Keith Lawson 2014-03-02 17:54 ` Frank Schäfer 0 siblings, 1 reply; 12+ messages in thread From: Keith Lawson @ 2014-02-27 1:47 UTC (permalink / raw) To: Frank Schäfer; +Cc: Linux Media Mailing List 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 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 > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-02-27 1:47 ` Keith Lawson @ 2014-03-02 17:54 ` Frank Schäfer 2014-03-04 1:14 ` Keith Lawson 0 siblings, 1 reply; 12+ messages in thread From: Frank Schäfer @ 2014-03-02 17:54 UTC (permalink / raw) To: Keith Lawson; +Cc: Linux Media Mailing List 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 ? :-) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set 2014-03-02 17:54 ` Frank Schäfer @ 2014-03-04 1:14 ` Keith Lawson 0 siblings, 0 replies; 12+ messages in thread From: Keith Lawson @ 2014-03-04 1:14 UTC (permalink / raw) To: Frank Schäfer; +Cc: Linux Media Mailing List, keith.lawson 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Support for Empia 2980 video/audio capture chip set @ 2014-02-09 10:34 pepijn de vos 0 siblings, 0 replies; 12+ messages in thread From: pepijn de vos @ 2014-02-09 10:34 UTC (permalink / raw) To: linux-media@vger.kernel.org Hey, I signed up to this list because I found this thread in the archives when googling for a driver for my Dazzle. Unfortunately I can't reply to an email I did not get. Like Keith Lawson I'm a developer with no kernel experience, although I have some experience with C and libusb. I'd be happy to help in any way possible. If there are any Dutch linux-media developers we could do a little hackathon maybe? Unrelated: How do people manage to not be ovewhelmed by such a high-volume list? Cheers, Pepijn de Vos ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-03-04 1:14 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-09 1:02 Support for Empia 2980 video/audio capture chip set Keith Lawson 2014-01-12 16:56 ` Frank Schäfer 2014-01-14 0:48 ` Keith Lawson 2014-01-15 21:37 ` Frank Schäfer 2014-01-17 0:11 ` Keith Lawson 2014-01-20 20:08 ` Frank Schäfer 2014-02-06 12:57 ` Keith Lawson 2014-02-24 17:38 ` Frank Schäfer 2014-02-27 1:47 ` Keith Lawson 2014-03-02 17:54 ` Frank Schäfer 2014-03-04 1:14 ` Keith Lawson -- strict thread matches above, loose matches on Subject: below -- 2014-02-09 10:34 pepijn de vos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).
