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