Wrongly identified easycap em28xx

Wrongly identified easycap em28xx

[Mr Goldcove]

"Easy Cap DC-60++"
Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
resulting in no audio.
Works perfectly when using card 64 "Easy Cap Capture DC-60"

**Interim solution**
load module (before inserting the EasyCap. I'm having trouble if the
module is loaded/unloaded with different cards...)
modprobe em28xx card=64
  or
add "options em28xx card=64" to /etc/modprobe.d/local.conf

**hw info**
Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.

Chips:
Empia EM2860 P7JY8-011 201023-01AG
NXP SAA7113H
RMC ALC653 89G06K1 G909A

**logs**
[ 5567.367883] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
class 0)
[ 5567.367985] em28xx #0: chip ID is em2860
[ 5567.380645] IR MCE Keyboard/mouse protocol handler initialized
[ 5567.384202] lirc_dev: IR Remote Control driver registered, major 249
[ 5567.385468] IR LIRC bridge handler initialized
[ 5567.460386] em28xx #0: board has no eeprom
[ 5567.534612] em28xx #0: found i2c device @ 0x4a [saa7113h]
[ 5567.568303] em28xx #0: Your board has no unique USB ID.
[ 5567.568308] em28xx #0: A hint were successfully done, based on i2c
devicelist hash.
[ 5567.568312] em28xx #0: This method is not 100% failproof.
[ 5567.568314] em28xx #0: If the board were missdetected, please email
this log to:
[ 5567.568317] em28xx #0:     V4L Mailing List 
<linux-media@vger.kernel.org>
[ 5567.568321] em28xx #0: Board detected as EM2860/SAA711X Reference Design
[ 5567.647433] em28xx #0: Identified as EM2860/SAA711X Reference Design
(card=19)
[ 5567.647438] em28xx #0: Registering snapshot button...
[ 5567.647531] input: em28xx snapshot button as
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/input/input11
[ 5568.019310] saa7115 15-0025: saa7113 found (1f7113d0e100000) @ 0x4a
(em28xx #0)
[ 5568.789385] em28xx #0: Config register raw data: 0x10
[ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761
[ 5568.825074] em28xx #0: AC97 features = 0x0000
[ 5568.825078] em28xx #0: Unknown AC97 audio processor detected!
[ 5569.284137] em28xx #0: v4l2 driver version 0.1.3
[ 5570.305831] em28xx #0: V4L2 video device registered as video1
[ 5570.305835] em28xx #0: V4L2 VBI device registered as vbi0
[ 5570.305862] em28xx audio device (eb1a:2861): interface 1, class 1
[ 5570.305877] em28xx audio device (eb1a:2861): interface 2, class 1
[ 5570.305906] usbcore: registered new interface driver em28xx
[ 5570.305909] em28xx driver loaded
[ 5570.392917] usbcore: registered new interface driver snd-usb-audio
[ 7903.785365] em28xx #0: vidioc_s_fmt_vid_cap queue busy

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 18.02.2013 21:53, schrieb Mr Goldcove:
> "Easy Cap DC-60++"
> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
> resulting in no audio.
> Works perfectly when using card 64 "Easy Cap Capture DC-60"

Video inputs work fine, right ?
Does this device has any buttons / LEDs ?

The driver doesn't handle devices with generic IDs very well.
In this case we can conclude from the USB PID that the device has audio
support (which is actually the only difference to board
EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
But I would like to think twice about it, because this kind of changes
has very a high potential to cause regressions for other boards...

Regards,
Frank

>
> **Interim solution**
> load module (before inserting the EasyCap. I'm having trouble if the
> module is loaded/unloaded with different cards...)
> modprobe em28xx card=64
>   or
> add "options em28xx card=64" to /etc/modprobe.d/local.conf
>
> **hw info**
> Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.
>
> Chips:
> Empia EM2860 P7JY8-011 201023-01AG
> NXP SAA7113H
> RMC ALC653 89G06K1 G909A
>
> **logs**
> [ 5567.367883] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
> class 0)
> [ 5567.367985] em28xx #0: chip ID is em2860
> [ 5567.380645] IR MCE Keyboard/mouse protocol handler initialized
> [ 5567.384202] lirc_dev: IR Remote Control driver registered, major 249
> [ 5567.385468] IR LIRC bridge handler initialized
> [ 5567.460386] em28xx #0: board has no eeprom
> [ 5567.534612] em28xx #0: found i2c device @ 0x4a [saa7113h]
> [ 5567.568303] em28xx #0: Your board has no unique USB ID.
> [ 5567.568308] em28xx #0: A hint were successfully done, based on i2c
> devicelist hash.
> [ 5567.568312] em28xx #0: This method is not 100% failproof.
> [ 5567.568314] em28xx #0: If the board were missdetected, please email
> this log to:
> [ 5567.568317] em28xx #0:     V4L Mailing List 
> <linux-media@vger.kernel.org>
> [ 5567.568321] em28xx #0: Board detected as EM2860/SAA711X Reference Design
> [ 5567.647433] em28xx #0: Identified as EM2860/SAA711X Reference Design
> (card=19)
> [ 5567.647438] em28xx #0: Registering snapshot button...
> [ 5567.647531] input: em28xx snapshot button as
> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/input/input11
> [ 5568.019310] saa7115 15-0025: saa7113 found (1f7113d0e100000) @ 0x4a
> (em28xx #0)
> [ 5568.789385] em28xx #0: Config register raw data: 0x10
> [ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761
> [ 5568.825074] em28xx #0: AC97 features = 0x0000
> [ 5568.825078] em28xx #0: Unknown AC97 audio processor detected!
> [ 5569.284137] em28xx #0: v4l2 driver version 0.1.3
> [ 5570.305831] em28xx #0: V4L2 video device registered as video1
> [ 5570.305835] em28xx #0: V4L2 VBI device registered as vbi0
> [ 5570.305862] em28xx audio device (eb1a:2861): interface 1, class 1
> [ 5570.305877] em28xx audio device (eb1a:2861): interface 2, class 1
> [ 5570.305906] usbcore: registered new interface driver em28xx
> [ 5570.305909] em28xx driver loaded
> [ 5570.392917] usbcore: registered new interface driver snd-usb-audio
> [ 7903.785365] em28xx #0: vidioc_s_fmt_vid_cap queue busy
> --
> 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

Re: Wrongly identified easycap em28xx

[Mr Goldcove]

I've only tried composite video input.
The video/ audio output is good.
 
It has the following input:
RCA stereo sound
RCA video
S-video

It has no push button but has a green led which illuminates when the
device is in use.


On 18. feb. 2013 22:25, Frank Schäfer wrote:
> Am 18.02.2013 21:53, schrieb Mr Goldcove:
>> "Easy Cap DC-60++"
>> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
>> resulting in no audio.
>> Works perfectly when using card 64 "Easy Cap Capture DC-60"
> Video inputs work fine, right ?
> Does this device has any buttons / LEDs ?
>
> The driver doesn't handle devices with generic IDs very well.
> In this case we can conclude from the USB PID that the device has audio
> support (which is actually the only difference to board
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
> But I would like to think twice about it, because this kind of changes
> has very a high potential to cause regressions for other boards...
>
> Regards,
> Frank
>
>> **Interim solution**
>> load module (before inserting the EasyCap. I'm having trouble if the
>> module is loaded/unloaded with different cards...)
>> modprobe em28xx card=64
>>   or
>> add "options em28xx card=64" to /etc/modprobe.d/local.conf
>>
>> **hw info**
>> Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.
>>
>> Chips:
>> Empia EM2860 P7JY8-011 201023-01AG
>> NXP SAA7113H
>> RMC ALC653 89G06K1 G909A
>>
>> **logs**
>> [ 5567.367883] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
>> class 0)
>> [ 5567.367985] em28xx #0: chip ID is em2860
>> [ 5567.380645] IR MCE Keyboard/mouse protocol handler initialized
>> [ 5567.384202] lirc_dev: IR Remote Control driver registered, major 249
>> [ 5567.385468] IR LIRC bridge handler initialized
>> [ 5567.460386] em28xx #0: board has no eeprom
>> [ 5567.534612] em28xx #0: found i2c device @ 0x4a [saa7113h]
>> [ 5567.568303] em28xx #0: Your board has no unique USB ID.
>> [ 5567.568308] em28xx #0: A hint were successfully done, based on i2c
>> devicelist hash.
>> [ 5567.568312] em28xx #0: This method is not 100% failproof.
>> [ 5567.568314] em28xx #0: If the board were missdetected, please email
>> this log to:
>> [ 5567.568317] em28xx #0:     V4L Mailing List 
>> <linux-media@vger.kernel.org>
>> [ 5567.568321] em28xx #0: Board detected as EM2860/SAA711X Reference Design
>> [ 5567.647433] em28xx #0: Identified as EM2860/SAA711X Reference Design
>> (card=19)
>> [ 5567.647438] em28xx #0: Registering snapshot button...
>> [ 5567.647531] input: em28xx snapshot button as
>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/input/input11
>> [ 5568.019310] saa7115 15-0025: saa7113 found (1f7113d0e100000) @ 0x4a
>> (em28xx #0)
>> [ 5568.789385] em28xx #0: Config register raw data: 0x10
>> [ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761
>> [ 5568.825074] em28xx #0: AC97 features = 0x0000
>> [ 5568.825078] em28xx #0: Unknown AC97 audio processor detected!
>> [ 5569.284137] em28xx #0: v4l2 driver version 0.1.3
>> [ 5570.305831] em28xx #0: V4L2 video device registered as video1
>> [ 5570.305835] em28xx #0: V4L2 VBI device registered as vbi0
>> [ 5570.305862] em28xx audio device (eb1a:2861): interface 1, class 1
>> [ 5570.305877] em28xx audio device (eb1a:2861): interface 2, class 1
>> [ 5570.305906] usbcore: registered new interface driver em28xx
>> [ 5570.305909] em28xx driver loaded
>> [ 5570.392917] usbcore: registered new interface driver snd-usb-audio
>> [ 7903.785365] em28xx #0: vidioc_s_fmt_vid_cap queue busy
>> --
>> 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

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 18.02.2013 23:36, schrieb Mr Goldcove:
> I've only tried composite video input.
> The video/ audio output is good.
>  
> It has the following input:
> RCA stereo sound
> RCA video
> S-video
>
> It has no push button but has a green led which illuminates when the
> device is in use.

Ok, could you please post the output of "lsusb -v -d eb1a:2861" ?

Regards,
Frank

>
> On 18. feb. 2013 22:25, Frank Schäfer wrote:
>> Am 18.02.2013 21:53, schrieb Mr Goldcove:
>>> "Easy Cap DC-60++"
>>> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
>>> resulting in no audio.
>>> Works perfectly when using card 64 "Easy Cap Capture DC-60"
>> Video inputs work fine, right ?
>> Does this device has any buttons / LEDs ?
>>
>> The driver doesn't handle devices with generic IDs very well.
>> In this case we can conclude from the USB PID that the device has audio
>> support (which is actually the only difference to board
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
>> But I would like to think twice about it, because this kind of changes
>> has very a high potential to cause regressions for other boards...
>>
>> Regards,
>> Frank
>>
>>> **Interim solution**
>>> load module (before inserting the EasyCap. I'm having trouble if the
>>> module is loaded/unloaded with different cards...)
>>> modprobe em28xx card=64
>>>   or
>>> add "options em28xx card=64" to /etc/modprobe.d/local.conf
>>>
>>> **hw info**
>>> Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.
>>>
>>> Chips:
>>> Empia EM2860 P7JY8-011 201023-01AG
>>> NXP SAA7113H
>>> RMC ALC653 89G06K1 G909A
>>>
>>> **logs**
>>> [ 5567.367883] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
>>> class 0)
>>> [ 5567.367985] em28xx #0: chip ID is em2860
>>> [ 5567.380645] IR MCE Keyboard/mouse protocol handler initialized
>>> [ 5567.384202] lirc_dev: IR Remote Control driver registered, major 249
>>> [ 5567.385468] IR LIRC bridge handler initialized
>>> [ 5567.460386] em28xx #0: board has no eeprom
>>> [ 5567.534612] em28xx #0: found i2c device @ 0x4a [saa7113h]
>>> [ 5567.568303] em28xx #0: Your board has no unique USB ID.
>>> [ 5567.568308] em28xx #0: A hint were successfully done, based on i2c
>>> devicelist hash.
>>> [ 5567.568312] em28xx #0: This method is not 100% failproof.
>>> [ 5567.568314] em28xx #0: If the board were missdetected, please email
>>> this log to:
>>> [ 5567.568317] em28xx #0:     V4L Mailing List 
>>> <linux-media@vger.kernel.org>
>>> [ 5567.568321] em28xx #0: Board detected as EM2860/SAA711X Reference Design
>>> [ 5567.647433] em28xx #0: Identified as EM2860/SAA711X Reference Design
>>> (card=19)
>>> [ 5567.647438] em28xx #0: Registering snapshot button...
>>> [ 5567.647531] input: em28xx snapshot button as
>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/input/input11
>>> [ 5568.019310] saa7115 15-0025: saa7113 found (1f7113d0e100000) @ 0x4a
>>> (em28xx #0)
>>> [ 5568.789385] em28xx #0: Config register raw data: 0x10
>>> [ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761
>>> [ 5568.825074] em28xx #0: AC97 features = 0x0000
>>> [ 5568.825078] em28xx #0: Unknown AC97 audio processor detected!
>>> [ 5569.284137] em28xx #0: v4l2 driver version 0.1.3
>>> [ 5570.305831] em28xx #0: V4L2 video device registered as video1
>>> [ 5570.305835] em28xx #0: V4L2 VBI device registered as vbi0
>>> [ 5570.305862] em28xx audio device (eb1a:2861): interface 1, class 1
>>> [ 5570.305877] em28xx audio device (eb1a:2861): interface 2, class 1
>>> [ 5570.305906] usbcore: registered new interface driver em28xx
>>> [ 5570.305909] em28xx driver loaded
>>> [ 5570.392917] usbcore: registered new interface driver snd-usb-audio
>>> [ 7903.785365] em28xx #0: vidioc_s_fmt_vid_cap queue busy
>>> --
>>> 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

Re: Wrongly identified easycap em28xx

[Mr Goldcove]

On 19. feb. 2013 17:02, Frank Schäfer wrote:
> Am 18.02.2013 23:36, schrieb Mr Goldcove:
>> > I've only tried composite video input.
>> > The video/ audio output is good.
>> >  
>> > It has the following input:
>> > RCA stereo sound
>> > RCA video
>> > S-video
>> >
>> > It has no push button but has a green led which illuminates when the
>> > device is in use.
> Ok, could you please post the output of "lsusb -v -d eb1a:2861" ?
>
> Regards,
> Frank
>

Bus 002 Device 004: ID eb1a:2861 eMPIA Technology, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0xeb1a eMPIA Technology, Inc.
  idProduct          0x2861
  bcdDevice            1.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          555
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       2
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0ad4  2x 724 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       3
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0c00  2x 1024 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       4
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x1300  3x 768 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       5
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x135c  3x 860 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       6
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x13c4  3x 964 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       7
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              11
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x1400  3x 1024 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0
      iInterface              0
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength           39
        bInCollection           1
        baInterfaceNr( 0)       2
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0603 Line Connector
        bAssocTerminal          0
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0
        iTerminal               0
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      6 (FEATURE_UNIT)
        bUnitID                 2
        bSourceID               1
        bControlSize            1
        bmaControls( 0)      0x03
          Mute Control
          Volume Control
        bmaControls( 1)      0x00
        iFeature                0
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             3
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          0
        bSourceID               2
        iTerminal               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]            0
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0000  1x 0 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00c4  1x 196 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        44100
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x00b4  1x 180 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        32000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0084  1x 132 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       4
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        16000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0044  1x 68 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       5
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0
      iInterface              0
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]         8000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0024  1x 36 bytes
        bInterval               4
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 18.02.2013 23:36, schrieb Mr Goldcove:
> I've only tried composite video input.
> The video/ audio output is good.
>  
> It has the following input:
> RCA stereo sound
> RCA video
> S-video
>
> It has no push button but has a green led which illuminates when the
> device is in use.
>
>
> On 18. feb. 2013 22:25, Frank Schäfer wrote:
>> Am 18.02.2013 21:53, schrieb Mr Goldcove:
>>> "Easy Cap DC-60++"
>>> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
>>> resulting in no audio.
>>> Works perfectly when using card 64 "Easy Cap Capture DC-60"
>> Video inputs work fine, right ?
>> Does this device has any buttons / LEDs ?
>>
>> The driver doesn't handle devices with generic IDs very well.
>> In this case we can conclude from the USB PID that the device has audio
>> support (which is actually the only difference to board
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
>> But I would like to think twice about it, because this kind of changes
>> has very a high potential to cause regressions for other boards...
>>
>> Regards,
>> Frank

After thinking about this for some minutes:
The easiest soulution would be, to add .amux = EM28XX_AMUX_LINE_IN lines
to input definitions of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN.
No additional code lines (check for audio support etc.) would be needed
and (as side effect) board EM2860_BOARD_EASYCAP would become obsolete.

The last modification of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN was
commit 3ed58baf5db4eab553803916a990a3dbca4dc611 from Devin.
The commit message says

"The device provides the audio through a pass-thru cable, so we don't need
 an actual audio capture profile (neither the K-World device nor the
Pointnix
 have an onboard audio decoder)"

Changing the .amux settings doesn't cause any trouble for devices
without audio support
(there is actually no way to define _no_ amux, without this line in the
input definition .amux is 0 = EM28XX_AMUX_VIDEO).

BUT: as we are talking about devices with generic USB IDs, we don't (and
will never) know about all other existing devices.
There _might_ be some unknown devices with audio support, which are
working silently with the current audio settings for board
EM2860_BOARD_SAA711X_REFERENCE_DESIGN.

OTOH: if we keep the two separate boards and switch from board
EM2860_BOARD_SAA711X_REFERENCE_DESIGN to board EM2860_BOARD_EASYCAP when
the device has audio support,
the same shit can happen.

Thoughts ?
Does anyone know how the Empia-driver handles devices with generic IDs ?
Do you think we can assume their driver uses a single reference board
design for the detected combination of USB-ID and subdevices ?

Regards,
Frank



>>
>>> **Interim solution**
>>> load module (before inserting the EasyCap. I'm having trouble if the
>>> module is loaded/unloaded with different cards...)
>>> modprobe em28xx card=64
>>>   or
>>> add "options em28xx card=64" to /etc/modprobe.d/local.conf
>>>
>>> **hw info**
>>> Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.
>>>
>>> Chips:
>>> Empia EM2860 P7JY8-011 201023-01AG
>>> NXP SAA7113H
>>> RMC ALC653 89G06K1 G909A
>>>
>>> **logs**
>>> [ 5567.367883] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
>>> class 0)
>>> [ 5567.367985] em28xx #0: chip ID is em2860
>>> [ 5567.380645] IR MCE Keyboard/mouse protocol handler initialized
>>> [ 5567.384202] lirc_dev: IR Remote Control driver registered, major 249
>>> [ 5567.385468] IR LIRC bridge handler initialized
>>> [ 5567.460386] em28xx #0: board has no eeprom
>>> [ 5567.534612] em28xx #0: found i2c device @ 0x4a [saa7113h]
>>> [ 5567.568303] em28xx #0: Your board has no unique USB ID.
>>> [ 5567.568308] em28xx #0: A hint were successfully done, based on i2c
>>> devicelist hash.
>>> [ 5567.568312] em28xx #0: This method is not 100% failproof.
>>> [ 5567.568314] em28xx #0: If the board were missdetected, please email
>>> this log to:
>>> [ 5567.568317] em28xx #0:     V4L Mailing List 
>>> <linux-media@vger.kernel.org>
>>> [ 5567.568321] em28xx #0: Board detected as EM2860/SAA711X Reference Design
>>> [ 5567.647433] em28xx #0: Identified as EM2860/SAA711X Reference Design
>>> (card=19)
>>> [ 5567.647438] em28xx #0: Registering snapshot button...
>>> [ 5567.647531] input: em28xx snapshot button as
>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/input/input11
>>> [ 5568.019310] saa7115 15-0025: saa7113 found (1f7113d0e100000) @ 0x4a
>>> (em28xx #0)
>>> [ 5568.789385] em28xx #0: Config register raw data: 0x10
>>> [ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761
>>> [ 5568.825074] em28xx #0: AC97 features = 0x0000
>>> [ 5568.825078] em28xx #0: Unknown AC97 audio processor detected!
>>> [ 5569.284137] em28xx #0: v4l2 driver version 0.1.3
>>> [ 5570.305831] em28xx #0: V4L2 video device registered as video1
>>> [ 5570.305835] em28xx #0: V4L2 VBI device registered as vbi0
>>> [ 5570.305862] em28xx audio device (eb1a:2861): interface 1, class 1
>>> [ 5570.305877] em28xx audio device (eb1a:2861): interface 2, class 1
>>> [ 5570.305906] usbcore: registered new interface driver em28xx
>>> [ 5570.305909] em28xx driver loaded
>>> [ 5570.392917] usbcore: registered new interface driver snd-usb-audio
>>> [ 7903.785365] em28xx #0: vidioc_s_fmt_vid_cap queue busy
>>> --
>>> 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

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Tue, 19 Feb 2013 17:47:28 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 18.02.2013 23:36, schrieb Mr Goldcove:
> > I've only tried composite video input.
> > The video/ audio output is good.
> >  
> > It has the following input:
> > RCA stereo sound
> > RCA video
> > S-video
> >
> > It has no push button but has a green led which illuminates when the
> > device is in use.
> >
> >
> > On 18. feb. 2013 22:25, Frank Schäfer wrote:
> >> Am 18.02.2013 21:53, schrieb Mr Goldcove:
> >>> "Easy Cap DC-60++"
> >>> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
> >>> resulting in no audio.
> >>> Works perfectly when using card 64 "Easy Cap Capture DC-60"
> >> Video inputs work fine, right ?
> >> Does this device has any buttons / LEDs ?
> >>
> >> The driver doesn't handle devices with generic IDs very well.
> >> In this case we can conclude from the USB PID that the device has audio
> >> support (which is actually the only difference to board
> >> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
> >> But I would like to think twice about it, because this kind of changes
> >> has very a high potential to cause regressions for other boards...
> >>
> >> Regards,
> >> Frank
> 
> After thinking about this for some minutes:
> The easiest soulution would be, to add .amux = EM28XX_AMUX_LINE_IN lines
> to input definitions of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN.
> No additional code lines (check for audio support etc.) would be needed
> and (as side effect) board EM2860_BOARD_EASYCAP would become obsolete.
> 
> The last modification of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN was
> commit 3ed58baf5db4eab553803916a990a3dbca4dc611 from Devin.
> The commit message says
> 
> "The device provides the audio through a pass-thru cable, so we don't need
>  an actual audio capture profile (neither the K-World device nor the
> Pointnix
>  have an onboard audio decoder)"
> 
> Changing the .amux settings doesn't cause any trouble for devices
> without audio support
> (there is actually no way to define _no_ amux, without this line in the
> input definition .amux is 0 = EM28XX_AMUX_VIDEO).
> 
> BUT: as we are talking about devices with generic USB IDs, we don't (and
> will never) know about all other existing devices.
> There _might_ be some unknown devices with audio support, which are
> working silently with the current audio settings for board
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN.
> 
> OTOH: if we keep the two separate boards and switch from board
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN to board EM2860_BOARD_EASYCAP when
> the device has audio support,
> the same shit can happen.
> 
> Thoughts ?
>
> Does anyone know how the Empia-driver handles devices with generic IDs ?
> Do you think we can assume their driver uses a single reference board
> design for the detected combination of USB-ID and subdevices ?
> 

I don't like the idea of merging those two entries. As far as I remember
there are devices that works out of the box with
EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
the driver for them.


Regards,
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 19.02.2013 19:30, schrieb Mauro Carvalho Chehab:
> Em Tue, 19 Feb 2013 17:47:28 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>> Am 18.02.2013 23:36, schrieb Mr Goldcove:
>>> I've only tried composite video input.
>>> The video/ audio output is good.
>>>  
>>> It has the following input:
>>> RCA stereo sound
>>> RCA video
>>> S-video
>>>
>>> It has no push button but has a green led which illuminates when the
>>> device is in use.
>>>
>>>
>>> On 18. feb. 2013 22:25, Frank Schäfer wrote:
>>>> Am 18.02.2013 21:53, schrieb Mr Goldcove:
>>>>> "Easy Cap DC-60++"
>>>>> Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
>>>>> resulting in no audio.
>>>>> Works perfectly when using card 64 "Easy Cap Capture DC-60"
>>>> Video inputs work fine, right ?
>>>> Does this device has any buttons / LEDs ?
>>>>
>>>> The driver doesn't handle devices with generic IDs very well.
>>>> In this case we can conclude from the USB PID that the device has audio
>>>> support (which is actually the only difference to board
>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
>>>> But I would like to think twice about it, because this kind of changes
>>>> has very a high potential to cause regressions for other boards...
>>>>
>>>> Regards,
>>>> Frank
>> After thinking about this for some minutes:
>> The easiest soulution would be, to add .amux = EM28XX_AMUX_LINE_IN lines
>> to input definitions of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN.
>> No additional code lines (check for audio support etc.) would be needed
>> and (as side effect) board EM2860_BOARD_EASYCAP would become obsolete.
>>
>> The last modification of board EM2860_BOARD_SAA711X_REFERENCE_DESIGN was
>> commit 3ed58baf5db4eab553803916a990a3dbca4dc611 from Devin.
>> The commit message says
>>
>> "The device provides the audio through a pass-thru cable, so we don't need
>>  an actual audio capture profile (neither the K-World device nor the
>> Pointnix
>>  have an onboard audio decoder)"
>>
>> Changing the .amux settings doesn't cause any trouble for devices
>> without audio support
>> (there is actually no way to define _no_ amux, without this line in the
>> input definition .amux is 0 = EM28XX_AMUX_VIDEO).
>>
>> BUT: as we are talking about devices with generic USB IDs, we don't (and
>> will never) know about all other existing devices.
>> There _might_ be some unknown devices with audio support, which are
>> working silently with the current audio settings for board
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN.
>>
>> OTOH: if we keep the two separate boards and switch from board
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN to board EM2860_BOARD_EASYCAP when
>> the device has audio support,
>> the same shit can happen.
>>
>> Thoughts ?
>>
>> Does anyone know how the Empia-driver handles devices with generic IDs ?
>> Do you think we can assume their driver uses a single reference board
>> design for the detected combination of USB-ID and subdevices ?
>>
> I don't like the idea of merging those two entries. As far as I remember
> there are devices that works out of the box with
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> the driver for them.

As described above, there is a good chance to break devices with both
solutions.

What's your suggestion ? ;-)

Regards,
Frank


> Regards,
> Mauro

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Tue, 19 Feb 2013 19:45:29 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> > I don't like the idea of merging those two entries. As far as I remember
> > there are devices that works out of the box with
> > EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> > the driver for them.
> 
> As described above, there is a good chance to break devices with both
> solutions.
> 
> What's your suggestion ? ;-)
> 

As I said, just leave it as-is (documenting at web) or to use the AC97
chip ID as a hint. This works fine for devices that don't come with
Empiatech em202, but with something else, like the case of the Realtek
chip found on this device. The reference design for sure uses em202.

-- 

Cheers,
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
> Em Tue, 19 Feb 2013 19:45:29 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>>> I don't like the idea of merging those two entries. As far as I remember
>>> there are devices that works out of the box with
>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
>>> the driver for them.
>> As described above, there is a good chance to break devices with both
>> solutions.
>>
>> What's your suggestion ? ;-)
>>
> As I said, just leave it as-is (documenting at web) 

That seems to be indeed the only 100%-regression-safe solution.
But also _no_ solution for this device.
A device which works only with a special module parameter passed on
driver loading isn't much better than an unsupported device.

It comes down to the following question:
Do we want to refuse fixing known/existing devices for the sake of
avoiding regression for unknown devices which even might not exist ? ;-)

I have no strong and final opinion yet. Still hoping someone knows how
the Empia driver handles these cases...


> or to use the AC97
> chip ID as a hint. This works fine for devices that don't come with
> Empiatech em202, but with something else, like the case of the Realtek
> chip found on this device. The reference design for sure uses em202.

How could the AC97 chip ID help us in this situation ?
As far as I understand, it doesn't matter which AC97 IC is used.
They are all compatible and at least our driver uses the same code for
all of them.

So even if you are are right and the Empia reference design uses an EMP202,
EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
AC97-ICs, too.
We should also expect manufacturers to switch between them whenever they
want (e.g. because of price changes).

Regards,
Frank

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Tue, 19 Feb 2013 20:45:21 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
> > Em Tue, 19 Feb 2013 19:45:29 +0100
> > Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> >
> >>> I don't like the idea of merging those two entries. As far as I remember
> >>> there are devices that works out of the box with
> >>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> >>> the driver for them.
> >> As described above, there is a good chance to break devices with both
> >> solutions.
> >>
> >> What's your suggestion ? ;-)
> >>
> > As I said, just leave it as-is (documenting at web) 
> 
> That seems to be indeed the only 100%-regression-safe solution.
> But also _no_ solution for this device.
> A device which works only with a special module parameter passed on
> driver loading isn't much better than an unsupported device.

That's not true. There are dozens of devices that only work with
modprobe parameter (even ones with their own USB or PCI address). The thing
is that crappy vendors don't provide any way for a driver to detect what's
there, as their driver rely on some *.inf config file with those parameters
hardcoded.

We can't do any better than what's provided by the device.

> 
> It comes down to the following question:
> Do we want to refuse fixing known/existing devices for the sake of
> avoiding regression for unknown devices which even might not exist ? ;-)

HUH? As I said: there are devices that work with the other board entry.
If you remove the other entry, _then_ you'll be breaking the driver.

> I have no strong and final opinion yet. Still hoping someone knows how
> the Empia driver handles these cases...

What do you mean? The original driver? The parameters are hardcoded at the
*.inf file. Once you get the driver, the *.inf file contains all the
parameters for it to work there. If you have two empia devices with
different models, you can only use the second one after removing the
install for the first one.

> > or to use the AC97
> > chip ID as a hint. This works fine for devices that don't come with
> > Empiatech em202, but with something else, like the case of the Realtek
> > chip found on this device. The reference design for sure uses em202.
> 
> How could the AC97 chip ID help us in this situation ?
> As far as I understand, it doesn't matter which AC97 IC is used.
> They are all compatible and at least our driver uses the same code for
> all of them.

The em28xx Kernel driver uses a hint code to try to identify the device
model. That hint code is not perfect, but it is the better we can do.

There are two hint codes there, currently: 
1) device's eeprom hash, used when the device has an eeprom, but the
   USB ID is not unique;

2) I2C scan bus hash: sometimes, different devices use different I2C
addresses.

> 
> So even if you are are right and the Empia reference design uses an EMP202,
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
> AC97-ICs, too.

The vast majority of devices use emp202. There are very few ones using
different models.

The proposal here is to add a third hint code, that would distinguish
the devices based on the ac97 ID.

> We should also expect manufacturers to switch between them whenever they
> want (e.g. because of price changes).

Yes, and then we'll need other entries at the hint table.

Regards
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 19.02.2013 21:03, schrieb Mauro Carvalho Chehab:
> Em Tue, 19 Feb 2013 20:45:21 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>> Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
>>> Em Tue, 19 Feb 2013 19:45:29 +0100
>>> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>>>
>>>>> I don't like the idea of merging those two entries. As far as I remember
>>>>> there are devices that works out of the box with
>>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
>>>>> the driver for them.
>>>> As described above, there is a good chance to break devices with both
>>>> solutions.
>>>>
>>>> What's your suggestion ? ;-)
>>>>
>>> As I said, just leave it as-is (documenting at web) 
>> That seems to be indeed the only 100%-regression-safe solution.
>> But also _no_ solution for this device.
>> A device which works only with a special module parameter passed on
>> driver loading isn't much better than an unsupported device.
> That's not true. There are dozens of devices that only work with
> modprobe parameter (even ones with their own USB or PCI address).

So the fact that we handle plenty devices this way makes the situation
for the user better ? ;-)
Not really !

>  The thing
> is that crappy vendors don't provide any way for a driver to detect what's
> there, as their driver rely on some *.inf config file with those parameters
> hardcoded.
>
> We can't do any better than what's provided by the device.
>
>> It comes down to the following question:
>> Do we want to refuse fixing known/existing devices for the sake of
>> avoiding regression for unknown devices which even might not exist ? ;-)
> HUH? As I said: there are devices that work with the other board entry.
> If you remove the other entry, _then_ you'll be breaking the driver.

Which devices _with_audio_support_ are working with
EM2860_BOARD_SAA711X_REFERENCE_DESIGN ?

AFAIK, the existence of such a device is pure theory at the moment.
But the Easycap DC-60 is reality !


>
>> I have no strong and final opinion yet. Still hoping someone knows how
>> the Empia driver handles these cases...
> What do you mean? The original driver? The parameters are hardcoded at the
> *.inf file. Once you get the driver, the *.inf file contains all the
> parameters for it to work there. If you have two empia devices with
> different models, you can only use the second one after removing the
> install for the first one.

Are you sure about that ? That's the worst case.

>
>>> or to use the AC97
>>> chip ID as a hint. This works fine for devices that don't come with
>>> Empiatech em202, but with something else, like the case of the Realtek
>>> chip found on this device. The reference design for sure uses em202.
>> How could the AC97 chip ID help us in this situation ?
>> As far as I understand, it doesn't matter which AC97 IC is used.
>> They are all compatible and at least our driver uses the same code for
>> all of them.
> The em28xx Kernel driver uses a hint code to try to identify the device
> model. That hint code is not perfect, but it is the better we can do.
>
> There are two hint codes there, currently: 
> 1) device's eeprom hash, used when the device has an eeprom, but the
>    USB ID is not unique;
>
> 2) I2C scan bus hash: sometimes, different devices use different I2C
> addresses.

???

Again, how can the AC97 chip ID help us in this situation ?
You just described the current board hint mechanism which clearly fails
in this case.

>
>> So even if you are are right and the Empia reference design uses an EMP202,
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
>> AC97-ICs, too.
> The vast majority of devices use emp202. There are very few ones using
> different models.
>
> The proposal here is to add a third hint code, that would distinguish
> the devices based on the ac97 ID.

I already explained why this is a potential source for regressions, too.

Regards,
Frank


>
>> We should also expect manufacturers to switch between them whenever they
>> want (e.g. because of price changes).
> Yes, and then we'll need other entries at the hint table.
>
> Regards
> Mauro

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Tue, 19 Feb 2013 23:14:38 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 19.02.2013 21:03, schrieb Mauro Carvalho Chehab:
> > Em Tue, 19 Feb 2013 20:45:21 +0100
> > Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> >
> >> Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
> >>> Em Tue, 19 Feb 2013 19:45:29 +0100
> >>> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> >>>
> >>>>> I don't like the idea of merging those two entries. As far as I remember
> >>>>> there are devices that works out of the box with
> >>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> >>>>> the driver for them.
> >>>> As described above, there is a good chance to break devices with both
> >>>> solutions.
> >>>>
> >>>> What's your suggestion ? ;-)
> >>>>
> >>> As I said, just leave it as-is (documenting at web) 
> >> That seems to be indeed the only 100%-regression-safe solution.
> >> But also _no_ solution for this device.
> >> A device which works only with a special module parameter passed on
> >> driver loading isn't much better than an unsupported device.
> > That's not true. There are dozens of devices that only work with
> > modprobe parameter (even ones with their own USB or PCI address).
> 
> So the fact that we handle plenty devices this way makes the situation
> for the user better ? ;-)
> Not really !
> 
> >  The thing
> > is that crappy vendors don't provide any way for a driver to detect what's
> > there, as their driver rely on some *.inf config file with those parameters
> > hardcoded.
> >
> > We can't do any better than what's provided by the device.
> >
> >> It comes down to the following question:
> >> Do we want to refuse fixing known/existing devices for the sake of
> >> avoiding regression for unknown devices which even might not exist ? ;-)
> > HUH? As I said: there are devices that work with the other board entry.
> > If you remove the other entry, _then_ you'll be breaking the driver.
> 
> Which devices _with_audio_support_ are working with
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN ?
> 
> AFAIK, the existence of such a device is pure theory at the moment.
> But the Easycap DC-60 is reality !

See the mailing lists archives. This driver is older than linux-media ML,
and it used to have a separate em28xx mailing list in the past. Not sure
if are there any mirror preserving the old logs for the em28xx ML, as this
weren't hosted here.

Please, don't pretend that you know all supported em28xx devices.

> >> I have no strong and final opinion yet. Still hoping someone knows how
> >> the Empia driver handles these cases...
> > What do you mean? The original driver? The parameters are hardcoded at the
> > *.inf file. Once you get the driver, the *.inf file contains all the
> > parameters for it to work there. If you have two empia devices with
> > different models, you can only use the second one after removing the
> > install for the first one.
> 
> Are you sure about that ? That's the worst case.

Yes, I'm pretty sure about that.

> >>> or to use the AC97
> >>> chip ID as a hint. This works fine for devices that don't come with
> >>> Empiatech em202, but with something else, like the case of the Realtek
> >>> chip found on this device. The reference design for sure uses em202.
> >> How could the AC97 chip ID help us in this situation ?
> >> As far as I understand, it doesn't matter which AC97 IC is used.
> >> They are all compatible and at least our driver uses the same code for
> >> all of them.
> > The em28xx Kernel driver uses a hint code to try to identify the device
> > model. That hint code is not perfect, but it is the better we can do.
> >
> > There are two hint codes there, currently: 
> > 1) device's eeprom hash, used when the device has an eeprom, but the
> >    USB ID is not unique;
> >
> > 2) I2C scan bus hash: sometimes, different devices use different I2C
> > addresses.
> 
> ???
> 
> Again, how can the AC97 chip ID help us in this situation ?
> You just described the current board hint mechanism which clearly fails
> in this case.
> 
> >
> >> So even if you are are right and the Empia reference design uses an EMP202,
> >> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
> >> AC97-ICs, too.
> > The vast majority of devices use emp202. There are very few ones using
> > different models.
> >
> > The proposal here is to add a third hint code, that would distinguish
> > the devices based on the ac97 ID.
> 
> I already explained why this is a potential source for regressions, too.

Yes, that may mean that other devices will need other entries, if are out
there any device that looks like the reference design.

Yet, such device IS NOT the reference design, as it is very doubtful 
that Empia would be shipping their reference design with an AC97
chip manufactured by another vendor.

There are, however, lots of device that just gets the Empia reference
design as-is (the same applies to other vendors) and only "designs" a box with
their logo. This is specially true for simpler devices like capture boards,
where there are just a very few set of components on it.

Cheers,
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 19.02.2013 23:42, schrieb Mauro Carvalho Chehab:
> Em Tue, 19 Feb 2013 23:14:38 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>> Am 19.02.2013 21:03, schrieb Mauro Carvalho Chehab:
>>> Em Tue, 19 Feb 2013 20:45:21 +0100
>>> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>>>> It comes down to the following question:
>>>> Do we want to refuse fixing known/existing devices for the sake of
>>>> avoiding regression for unknown devices which even might not exist ? ;-)
>>> HUH? As I said: there are devices that work with the other board entry.
>>> If you remove the other entry, _then_ you'll be breaking the driver.
>> Which devices _with_audio_support_ are working with
>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN ?
>>
>> AFAIK, the existence of such a device is pure theory at the moment.
>> But the Easycap DC-60 is reality !
> See the mailing lists archives. This driver is older than linux-media ML,
> and it used to have a separate em28xx mailing list in the past. Not sure
> if are there any mirror preserving the old logs for the em28xx ML, as this
> weren't hosted here.

Poor argumentation.
No evidences, just speculations.

> Please, don't pretend that you know all supported em28xx devices.

Huh ???
I didn't do that. Instead I pointed out risk due to the fact that we do
_not_ know all existing devices.
It was actually _you_ who pretended to know such devices, but you failed
to show us at least one of them.


>>>> I have no strong and final opinion yet. Still hoping someone knows how
>>>> the Empia driver handles these cases...
>>> What do you mean? The original driver? The parameters are hardcoded at the
>>> *.inf file. Once you get the driver, the *.inf file contains all the
>>> parameters for it to work there. If you have two empia devices with
>>> different models, you can only use the second one after removing the
>>> install for the first one.
>> Are you sure about that ? That's the worst case.
> Yes, I'm pretty sure about that.
>
>>>>> or to use the AC97
>>>>> chip ID as a hint. This works fine for devices that don't come with
>>>>> Empiatech em202, but with something else, like the case of the Realtek
>>>>> chip found on this device. The reference design for sure uses em202.
>>>> How could the AC97 chip ID help us in this situation ?
>>>> As far as I understand, it doesn't matter which AC97 IC is used.
>>>> They are all compatible and at least our driver uses the same code for
>>>> all of them.
>>> The em28xx Kernel driver uses a hint code to try to identify the device
>>> model. That hint code is not perfect, but it is the better we can do.
>>>
>>> There are two hint codes there, currently: 
>>> 1) device's eeprom hash, used when the device has an eeprom, but the
>>>    USB ID is not unique;
>>>
>>> 2) I2C scan bus hash: sometimes, different devices use different I2C
>>> addresses.
>> ???
>>
>> Again, how can the AC97 chip ID help us in this situation ?
>> You just described the current board hint mechanism which clearly fails
>> in this case.
>>
>>>> So even if you are are right and the Empia reference design uses an EMP202,
>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
>>>> AC97-ICs, too.
>>> The vast majority of devices use emp202. There are very few ones using
>>> different models.
>>>
>>> The proposal here is to add a third hint code, that would distinguish
>>> the devices based on the ac97 ID.
>> I already explained why this is a potential source for regressions, too.
> Yes, that may mean that other devices will need other entries, if are out
> there any device that looks like the reference design.

So regressions are acceptable for you ?

> Yet, such device IS NOT the reference design, as it is very doubtful 
> that Empia would be shipping their reference design with an AC97
> chip manufactured by another vendor.

Hmm... you seem to make a lot of assumptions about board
EM2860_BOARD_SAA711X_REFERENCE_DESIGN...

Are you aware that it was called EM2860_BOARD_POINTNIX_INTRAORAL_CAMERA
before commit 3ed58baf ?
According to the commit message it seems like it has been renamed just
because a second device appeared.
The commit message also mentions that both devices known at this time
didn't have ("real") audio support, which is the reason why there is no
amux defined for the inputs.
So the audio configuration of this board is EM28XX_AMUX_VIDEO likely
just because there is no EM28XX_AMUX_NONE and noone ever tested it.

Why are you sure that this configuration matches the official Empia
reference board design (including the audio config) ?
Do you have any information from Empia about that ?

The second question is: do you think we can assume that the majority of
the devices with generic USB IDs are following the reference design ?

It should be easy to find out if the Easycap DC-60 follows the Empia
reference design by testing if it works with the generic Empia Windows
driver (http://home.eeti.com.tw/web20/eg/IC_support.htm).


Regards,
Frank

> There are, however, lots of device that just gets the Empia reference
> design as-is (the same applies to other vendors) and only "designs" a box with
> their logo. This is specially true for simpler devices like capture boards,
> where there are just a very few set of components on it.
>
> Cheers,
> Mauro

Re: Wrongly identified easycap em28xx

[Theodore Kilgore]

On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:

> Em Tue, 19 Feb 2013 20:45:21 +0100
> Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
> 
> > Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
> > > Em Tue, 19 Feb 2013 19:45:29 +0100
> > > Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
> > >
> > >>> I don't like the idea of merging those two entries. As far as I remember
> > >>> there are devices that works out of the box with
> > >>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> > >>> the driver for them.
> > >> As described above, there is a good chance to break devices with both
> > >> solutions.
> > >>
> > >> What's your suggestion ? ;-)
> > >>
> > > As I said, just leave it as-is (documenting at web) 
> > 
> > That seems to be indeed the only 100%-regression-safe solution.
> > But also _no_ solution for this device.
> > A device which works only with a special module parameter passed on
> > driver loading isn't much better than an unsupported device.
> 
> That's not true. There are dozens of devices that only work with
> modprobe parameter (even ones with their own USB or PCI address). The thing
> is that crappy vendors don't provide any way for a driver to detect what's
> there, as their driver rely on some *.inf config file with those parameters
> hardcoded.
> 
> We can't do any better than what's provided by the device.
> 
> > 
> > It comes down to the following question:
> > Do we want to refuse fixing known/existing devices for the sake of
> > avoiding regression for unknown devices which even might not exist ? ;-)
> 
> HUH? As I said: there are devices that work with the other board entry.
> If you remove the other entry, _then_ you'll be breaking the driver.
> 
> > I have no strong and final opinion yet. Still hoping someone knows how
> > the Empia driver handles these cases...
> 
> What do you mean? The original driver? The parameters are hardcoded at the
> *.inf file. Once you get the driver, the *.inf file contains all the
> parameters for it to work there. If you have two empia devices with
> different models, you can only use the second one after removing the
> install for the first one.
> 
> > > or to use the AC97
> > > chip ID as a hint. This works fine for devices that don't come with
> > > Empiatech em202, but with something else, like the case of the Realtek
> > > chip found on this device. The reference design for sure uses em202.
> > 
> > How could the AC97 chip ID help us in this situation ?
> > As far as I understand, it doesn't matter which AC97 IC is used.
> > They are all compatible and at least our driver uses the same code for
> > all of them.
> 
> The em28xx Kernel driver uses a hint code to try to identify the device
> model. That hint code is not perfect, but it is the better we can do.
> 
> There are two hint codes there, currently: 
> 1) device's eeprom hash, used when the device has an eeprom, but the
>    USB ID is not unique;
> 
> 2) I2C scan bus hash: sometimes, different devices use different I2C
> addresses.
> 
> > 
> > So even if you are are right and the Empia reference design uses an EMP202,
> > EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
> > AC97-ICs, too.
> 
> The vast majority of devices use emp202. There are very few ones using
> different models.
> 
> The proposal here is to add a third hint code, that would distinguish
> the devices based on the ac97 ID.
> 
> > We should also expect manufacturers to switch between them whenever they
> > want (e.g. because of price changes).
> 
> Yes, and then we'll need other entries at the hint table.
> 
> Regards
> Mauro

I see the dilemma. Devices which are not uniquely identifiable. Mauro is 
right in pinpointing the problem, and he is also right that one can not 
expect the manufacturers to pay any attention. Mauro is also absolutely 
right that it is not good to break what works already for some people, 
hoping to please some others who are presently unhappy. A better solution 
needs to be found.

Could I make a suggestion?

Sometimes it is possible to find some undocumented way to identify 
uniquely which one of two devices you have. As an example, look in 
mr97310a.c, where there is a detection routine for several devices which 
all have the same USB vendor:product code but are different inside. 

Indeed, back when lots of those mr97310a cameras were on the market, the 
"manufacturers" were supposed to be sending out the cameras with the 
"right" windows driver. Except the situation was actually so bad that 
quite often some of the manufacturers were grabbing the wrong driver CD 
off the shelf and putting it with the wrong cameras! You can do a Google 
search for the Windows driver for some of those cameras and find web pages 
full of complaints from disgruntled users who got the wrong CD in the 
package with the camera, frantically looking for the right driver CD. It 
was that bad. Now to top that off, think of some poor guy having a Windows 
computer and wanting to have two cameras of the same brand and make, with 
identical cases on the outside, but which needed different versions of the 
driver CD. And whichever driver is installed one of the two cameras will 
not work. Proof, BTW, that neither of those Windows drivers contains any 
detection routine.

The gspca_mr97310a module for Linux is the only support for those cameras 
for any operating system that I know of, which actually can tell one of 
those cameras from the other and apply the right initialiation to it when 
it is hooked up -- unless somebody has copied us since then.

The situation here looks to me similar. What someone needs to do is to 
find some kind of "read" command or sequence of commands (probably to the 
sensor, not to the controller) which will report a distinct answer for 
each of the various different cameras. Almost certainly, it will not be 
documented, but it almost certainly has to exist -- if for no other 
reason, because something is obviously different about the two pieces of 
hardware. So in my opinion the thing to do is to try to find that magic 
command. By a combination of educated guessing and trial and error. This 
needs for someone to have both cameras, or for two or more people who have 
the different cameras to cooperate together and hunt for the right command 
which unlocks the mystery.

I am out of this one because I don't have one of the cameras currently in 
question. But I did have a big pile of mr97310a cameras, and that is 
exactly what I did. Started sending various commands and checking whether 
or not I got different results until I found what works.

So, good luck. The answer is probably there if one looks for it.

My two cents,

Theodore Kilgore

Re: Wrongly identified easycap em28xx

[Andy Walls]

Theodore Kilgore <kilgota@banach.math.auburn.edu> wrote:

>
>
>On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:
>
>> Em Tue, 19 Feb 2013 20:45:21 +0100
>> Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
>> 
>> > Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
>> > > Em Tue, 19 Feb 2013 19:45:29 +0100
>> > > Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
>> > >
>> > >>> I don't like the idea of merging those two entries. As far as I
>remember
>> > >>> there are devices that works out of the box with
>> > >>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can
>break
>> > >>> the driver for them.
>> > >> As described above, there is a good chance to break devices with
>both
>> > >> solutions.
>> > >>
>> > >> What's your suggestion ? ;-)
>> > >>
>> > > As I said, just leave it as-is (documenting at web) 
>> > 
>> > That seems to be indeed the only 100%-regression-safe solution.
>> > But also _no_ solution for this device.
>> > A device which works only with a special module parameter passed on
>> > driver loading isn't much better than an unsupported device.
>> 
>> That's not true. There are dozens of devices that only work with
>> modprobe parameter (even ones with their own USB or PCI address). The
>thing
>> is that crappy vendors don't provide any way for a driver to detect
>what's
>> there, as their driver rely on some *.inf config file with those
>parameters
>> hardcoded.
>> 
>> We can't do any better than what's provided by the device.
>> 
>> > 
>> > It comes down to the following question:
>> > Do we want to refuse fixing known/existing devices for the sake of
>> > avoiding regression for unknown devices which even might not exist
>? ;-)
>> 
>> HUH? As I said: there are devices that work with the other board
>entry.
>> If you remove the other entry, _then_ you'll be breaking the driver.
>> 
>> > I have no strong and final opinion yet. Still hoping someone knows
>how
>> > the Empia driver handles these cases...
>> 
>> What do you mean? The original driver? The parameters are hardcoded
>at the
>> *.inf file. Once you get the driver, the *.inf file contains all the
>> parameters for it to work there. If you have two empia devices with
>> different models, you can only use the second one after removing the
>> install for the first one.
>> 
>> > > or to use the AC97
>> > > chip ID as a hint. This works fine for devices that don't come
>with
>> > > Empiatech em202, but with something else, like the case of the
>Realtek
>> > > chip found on this device. The reference design for sure uses
>em202.
>> > 
>> > How could the AC97 chip ID help us in this situation ?
>> > As far as I understand, it doesn't matter which AC97 IC is used.
>> > They are all compatible and at least our driver uses the same code
>for
>> > all of them.
>> 
>> The em28xx Kernel driver uses a hint code to try to identify the
>device
>> model. That hint code is not perfect, but it is the better we can do.
>> 
>> There are two hint codes there, currently: 
>> 1) device's eeprom hash, used when the device has an eeprom, but the
>>    USB ID is not unique;
>> 
>> 2) I2C scan bus hash: sometimes, different devices use different I2C
>> addresses.
>> 
>> > 
>> > So even if you are are right and the Empia reference design uses an
>EMP202,
>> > EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with
>other
>> > AC97-ICs, too.
>> 
>> The vast majority of devices use emp202. There are very few ones
>using
>> different models.
>> 
>> The proposal here is to add a third hint code, that would distinguish
>> the devices based on the ac97 ID.
>> 
>> > We should also expect manufacturers to switch between them whenever
>they
>> > want (e.g. because of price changes).
>> 
>> Yes, and then we'll need other entries at the hint table.
>> 
>> Regards
>> Mauro
>
>I see the dilemma. Devices which are not uniquely identifiable. Mauro
>is 
>right in pinpointing the problem, and he is also right that one can not
>
>expect the manufacturers to pay any attention. Mauro is also absolutely
>
>right that it is not good to break what works already for some people, 
>hoping to please some others who are presently unhappy. A better
>solution 
>needs to be found.
>
>Could I make a suggestion?
>
>Sometimes it is possible to find some undocumented way to identify 
>uniquely which one of two devices you have. As an example, look in 
>mr97310a.c, where there is a detection routine for several devices
>which 
>all have the same USB vendor:product code but are different inside. 
>
>Indeed, back when lots of those mr97310a cameras were on the market,
>the 
>"manufacturers" were supposed to be sending out the cameras with the 
>"right" windows driver. Except the situation was actually so bad that 
>quite often some of the manufacturers were grabbing the wrong driver CD
>
>off the shelf and putting it with the wrong cameras! You can do a
>Google 
>search for the Windows driver for some of those cameras and find web
>pages 
>full of complaints from disgruntled users who got the wrong CD in the 
>package with the camera, frantically looking for the right driver CD.
>It 
>was that bad. Now to top that off, think of some poor guy having a
>Windows 
>computer and wanting to have two cameras of the same brand and make,
>with 
>identical cases on the outside, but which needed different versions of
>the 
>driver CD. And whichever driver is installed one of the two cameras
>will 
>not work. Proof, BTW, that neither of those Windows drivers contains
>any 
>detection routine.
>
>The gspca_mr97310a module for Linux is the only support for those
>cameras 
>for any operating system that I know of, which actually can tell one of
>
>those cameras from the other and apply the right initialiation to it
>when 
>it is hooked up -- unless somebody has copied us since then.
>
>The situation here looks to me similar. What someone needs to do is to 
>find some kind of "read" command or sequence of commands (probably to
>the 
>sensor, not to the controller) which will report a distinct answer for 
>each of the various different cameras. Almost certainly, it will not be
>
>documented, but it almost certainly has to exist -- if for no other 
>reason, because something is obviously different about the two pieces
>of 
>hardware. So in my opinion the thing to do is to try to find that magic
>
>command. By a combination of educated guessing and trial and error.
>This 
>needs for someone to have both cameras, or for two or more people who
>have 
>the different cameras to cooperate together and hunt for the right
>command 
>which unlocks the mystery.
>
>I am out of this one because I don't have one of the cameras currently
>in 
>question. But I did have a big pile of mr97310a cameras, and that is 
>exactly what I did. Started sending various commands and checking
>whether 
>or not I got different results until I found what works.
>
>So, good luck. The answer is probably there if one looks for it.
>
>My two cents,
>
>Theodore Kilgore
>--
>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

Adding another example to Theodore's suggestion:

cx25840-core.c:cx25840_probe() has to go through a register inspection hueristic to distinguish between CX25843 cores used in the CX2388[578] chips, due to a useless ID register.

Regards,
Andy

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Tue, 19 Feb 2013 23:09:16 -0600 (CST)
Theodore Kilgore <kilgota@banach.math.auburn.edu> escreveu:

> 
> 
> On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:
> 
> > Em Tue, 19 Feb 2013 20:45:21 +0100
> > Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
> > 
> > > Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
> > > > Em Tue, 19 Feb 2013 19:45:29 +0100
> > > > Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
> > > >
> > > >>> I don't like the idea of merging those two entries. As far as I remember
> > > >>> there are devices that works out of the box with
> > > >>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
> > > >>> the driver for them.
> > > >> As described above, there is a good chance to break devices with both
> > > >> solutions.
> > > >>
> > > >> What's your suggestion ? ;-)
> > > >>
> > > > As I said, just leave it as-is (documenting at web) 
> > > 
> > > That seems to be indeed the only 100%-regression-safe solution.
> > > But also _no_ solution for this device.
> > > A device which works only with a special module parameter passed on
> > > driver loading isn't much better than an unsupported device.
> > 
> > That's not true. There are dozens of devices that only work with
> > modprobe parameter (even ones with their own USB or PCI address). The thing
> > is that crappy vendors don't provide any way for a driver to detect what's
> > there, as their driver rely on some *.inf config file with those parameters
> > hardcoded.
> > 
> > We can't do any better than what's provided by the device.
> > 
> > > 
> > > It comes down to the following question:
> > > Do we want to refuse fixing known/existing devices for the sake of
> > > avoiding regression for unknown devices which even might not exist ? ;-)
> > 
> > HUH? As I said: there are devices that work with the other board entry.
> > If you remove the other entry, _then_ you'll be breaking the driver.
> > 
> > > I have no strong and final opinion yet. Still hoping someone knows how
> > > the Empia driver handles these cases...
> > 
> > What do you mean? The original driver? The parameters are hardcoded at the
> > *.inf file. Once you get the driver, the *.inf file contains all the
> > parameters for it to work there. If you have two empia devices with
> > different models, you can only use the second one after removing the
> > install for the first one.
> > 
> > > > or to use the AC97
> > > > chip ID as a hint. This works fine for devices that don't come with
> > > > Empiatech em202, but with something else, like the case of the Realtek
> > > > chip found on this device. The reference design for sure uses em202.
> > > 
> > > How could the AC97 chip ID help us in this situation ?
> > > As far as I understand, it doesn't matter which AC97 IC is used.
> > > They are all compatible and at least our driver uses the same code for
> > > all of them.
> > 
> > The em28xx Kernel driver uses a hint code to try to identify the device
> > model. That hint code is not perfect, but it is the better we can do.
> > 
> > There are two hint codes there, currently: 
> > 1) device's eeprom hash, used when the device has an eeprom, but the
> >    USB ID is not unique;
> > 
> > 2) I2C scan bus hash: sometimes, different devices use different I2C
> > addresses.
> > 
> > > 
> > > So even if you are are right and the Empia reference design uses an EMP202,
> > > EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
> > > AC97-ICs, too.
> > 
> > The vast majority of devices use emp202. There are very few ones using
> > different models.
> > 
> > The proposal here is to add a third hint code, that would distinguish
> > the devices based on the ac97 ID.
> > 
> > > We should also expect manufacturers to switch between them whenever they
> > > want (e.g. because of price changes).
> > 
> > Yes, and then we'll need other entries at the hint table.
> > 
> > Regards
> > Mauro
> 
> I see the dilemma. Devices which are not uniquely identifiable. Mauro is 
> right in pinpointing the problem, and he is also right that one can not 
> expect the manufacturers to pay any attention. Mauro is also absolutely 
> right that it is not good to break what works already for some people, 
> hoping to please some others who are presently unhappy. A better solution 
> needs to be found.
> 
> Could I make a suggestion?
> 
> Sometimes it is possible to find some undocumented way to identify 
> uniquely which one of two devices you have. 

The hardware is identical, except for the audio decoder. Both devices have
only 3 chips on it: the em2860 chip, an saa7113 video decoder and the ac97
audio mixer, that it is different on each device. 

One board comes with an ac97 chip ID=0xffffffff [1](emp202, found on the
reference design and clones). The other one comes with an ac97 chip 
with ID=0x414c4761 (a Realtek ALC653, only found so far on EasyCap DC-60).

Btw, the issue between them is because of the different mixers found:
the mixer channel used by the DC-60 is different than the mixer channel
used by the reference design. At the reference design, the audio
channel is EM28XX_AMUX_VIDEO. At DC-60, it is EM28XX_AMUX_LINE_IN.

I can't think on any other way do distinguish between them except by
checking if the audio decoder matches the expected one.

Adding a logic for such check is simple enough, as the probing logic already
contains the needed bits for it.

[1] There is a variant of emp202 at address 0x83847650.

Regards,
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

<snip>

Am 20.02.2013 11:51, schrieb Mauro Carvalho Chehab:
> Em Tue, 19 Feb 2013 23:09:16 -0600 (CST)
> Theodore Kilgore <kilgota@banach.math.auburn.edu> escreveu:
>
>> On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:
>>
>>>> So even if you are are right and the Empia reference design uses an EMP202,
>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
>>>> AC97-ICs, too.
>>> The vast majority of devices use emp202. There are very few ones using
>>> different models.
>>>
>>> The proposal here is to add a third hint code, that would distinguish
>>> the devices based on the ac97 ID.
>>>
>>>> We should also expect manufacturers to switch between them whenever they
>>>> want (e.g. because of price changes).
>>> Yes, and then we'll need other entries at the hint table.
>>>
>>> Regards
>>> Mauro
>> I see the dilemma. Devices which are not uniquely identifiable. Mauro is 
>> right in pinpointing the problem, and he is also right that one can not 
>> expect the manufacturers to pay any attention. Mauro is also absolutely 
>> right that it is not good to break what works already for some people, 
>> hoping to please some others who are presently unhappy. A better solution 
>> needs to be found.
>>
>> Could I make a suggestion?
>>
>> Sometimes it is possible to find some undocumented way to identify 
>> uniquely which one of two devices you have. 
> The hardware is identical, except for the audio decoder. Both devices have
> only 3 chips on it: the em2860 chip, an saa7113 video decoder and the ac97
> audio mixer, that it is different on each device. 
>
> One board comes with an ac97 chip ID=0xffffffff [1](emp202, found on the
> reference design and clones). The other one comes with an ac97 chip 
> with ID=0x414c4761 (a Realtek ALC653, only found so far on EasyCap DC-60).
>
> Btw, the issue between them is because of the different mixers found:
> the mixer channel used by the DC-60 is different than the mixer channel
> used by the reference design. At the reference design, the audio
> channel is EM28XX_AMUX_VIDEO. At DC-60, it is EM28XX_AMUX_LINE_IN.

Now you got it.
The relevant difference is the _channel_configuration_, not the used
AC97 IC manufacturer+model.

> I can't think on any other way do distinguish between them except by
> checking if the audio decoder matches the expected one.
>
> Adding a logic for such check is simple enough, as the probing logic already
> contains the needed bits for it.

I'm not convinced, for the following reasons:
You can't infer from the usage of a particular AC97 IC how the device is
wired internally / which channel configuration it uses.
We also can't assume a fixed binding between a particular AC97 IC and a
product/board.

So _if_ we really decide to leave the conservative path and take the
risk of regressions for the sake of fixing other devices,
we should at least be sure that we fix more devices than we break. (Even
then it still sucks !)

Regards,
Frank

> [1] There is a variant of emp202 at address 0x83847650.
>
> Regards,
> Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 20.02.2013 06:09, schrieb Theodore Kilgore:
> On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:
>
>> Em Tue, 19 Feb 2013 20:45:21 +0100
>> Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
>>
>>> Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
>>>> Em Tue, 19 Feb 2013 19:45:29 +0100
>>>> Frank Sch?fer <fschaefer.oss@googlemail.com> escreveu:
>>>>
>>>>>> I don't like the idea of merging those two entries. As far as I remember
>>>>>> there are devices that works out of the box with
>>>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break
>>>>>> the driver for them.
>>>>> As described above, there is a good chance to break devices with both
>>>>> solutions.
>>>>>
>>>>> What's your suggestion ? ;-)
>>>>>
>>>> As I said, just leave it as-is (documenting at web) 
>>> That seems to be indeed the only 100%-regression-safe solution.
>>> But also _no_ solution for this device.
>>> A device which works only with a special module parameter passed on
>>> driver loading isn't much better than an unsupported device.
>> That's not true. There are dozens of devices that only work with
>> modprobe parameter (even ones with their own USB or PCI address). The thing
>> is that crappy vendors don't provide any way for a driver to detect what's
>> there, as their driver rely on some *.inf config file with those parameters
>> hardcoded.
>>
>> We can't do any better than what's provided by the device.
>>
>>> It comes down to the following question:
>>> Do we want to refuse fixing known/existing devices for the sake of
>>> avoiding regression for unknown devices which even might not exist ? ;-)
>> HUH? As I said: there are devices that work with the other board entry.
>> If you remove the other entry, _then_ you'll be breaking the driver.
>>
>>> I have no strong and final opinion yet. Still hoping someone knows how
>>> the Empia driver handles these cases...
>> What do you mean? The original driver? The parameters are hardcoded at the
>> *.inf file. Once you get the driver, the *.inf file contains all the
>> parameters for it to work there. If you have two empia devices with
>> different models, you can only use the second one after removing the
>> install for the first one.
>>
>>>> or to use the AC97
>>>> chip ID as a hint. This works fine for devices that don't come with
>>>> Empiatech em202, but with something else, like the case of the Realtek
>>>> chip found on this device. The reference design for sure uses em202.
>>> How could the AC97 chip ID help us in this situation ?
>>> As far as I understand, it doesn't matter which AC97 IC is used.
>>> They are all compatible and at least our driver uses the same code for
>>> all of them.
>> The em28xx Kernel driver uses a hint code to try to identify the device
>> model. That hint code is not perfect, but it is the better we can do.
>>
>> There are two hint codes there, currently: 
>> 1) device's eeprom hash, used when the device has an eeprom, but the
>>    USB ID is not unique;
>>
>> 2) I2C scan bus hash: sometimes, different devices use different I2C
>> addresses.
>>
>>> So even if you are are right and the Empia reference design uses an EMP202,
>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other
>>> AC97-ICs, too.
>> The vast majority of devices use emp202. There are very few ones using
>> different models.
>>
>> The proposal here is to add a third hint code, that would distinguish
>> the devices based on the ac97 ID.
>>
>>> We should also expect manufacturers to switch between them whenever they
>>> want (e.g. because of price changes).
>> Yes, and then we'll need other entries at the hint table.
>>
>> Regards
>> Mauro
> I see the dilemma. Devices which are not uniquely identifiable. Mauro is 
> right in pinpointing the problem, 

To be honest, it was _me_ who pointed out the dilemma here.

> and he is also right that one can not 
> expect the manufacturers to pay any attention. Mauro is also absolutely 
> right that it is not good to break what works already for some people, 
> hoping to please some others who are presently unhappy.

We all agree in this point (although it's actually the other way around
in this case - we would _verifiably_ fix the Easycap device and _might_
break others).
It's just as you said a few lines above - it's a dilemma.
And at the moment, it seems the only way to make sure we don't cause
regressions is to do nothing (=> use module parameters)

>  A better solution needs to be found.

That's what this discussion is about. ;-)

> Could I make a suggestion?
>
> Sometimes it is possible to find some undocumented way to identify 
> uniquely which one of two devices you have. As an example, look in 
> mr97310a.c, where there is a detection routine for several devices which 
> all have the same USB vendor:product code but are different inside. 
>
> Indeed, back when lots of those mr97310a cameras were on the market, the 
> "manufacturers" were supposed to be sending out the cameras with the 
> "right" windows driver. Except the situation was actually so bad that 
> quite often some of the manufacturers were grabbing the wrong driver CD 
> off the shelf and putting it with the wrong cameras! You can do a Google 
> search for the Windows driver for some of those cameras and find web pages 
> full of complaints from disgruntled users who got the wrong CD in the 
> package with the camera, frantically looking for the right driver CD. It 
> was that bad. Now to top that off, think of some poor guy having a Windows 
> computer and wanting to have two cameras of the same brand and make, with 
> identical cases on the outside, but which needed different versions of the 
> driver CD. And whichever driver is installed one of the two cameras will 
> not work. Proof, BTW, that neither of those Windows drivers contains any 
> detection routine.
>
> The gspca_mr97310a module for Linux is the only support for those cameras 
> for any operating system that I know of, which actually can tell one of 
> those cameras from the other and apply the right initialiation to it when 
> it is hooked up -- unless somebody has copied us since then.
>
> The situation here looks to me similar. What someone needs to do is to 
> find some kind of "read" command or sequence of commands (probably to the 
> sensor, not to the controller) which will report a distinct answer for 
> each of the various different cameras. Almost certainly, it will not be 
> documented, but it almost certainly has to exist -- if for no other 
> reason, because something is obviously different about the two pieces of 
> hardware. So in my opinion the thing to do is to try to find that magic 
> command. By a combination of educated guessing and trial and error. This 
> needs for someone to have both cameras, or for two or more people who have 
> the different cameras to cooperate together and hunt for the right command 
> which unlocks the mystery.
>
> I am out of this one because I don't have one of the cameras currently in 
> question. But I did have a big pile of mr97310a cameras, and that is 
> exactly what I did. Started sending various commands and checking whether 
> or not I got different results until I found what works.
>
> So, good luck. The answer is probably there if one looks for it.

The problem is, we don't have other devices at the moment for comparision.
And the second but more serious problems is, that we don't start from zero.
There _is_ already a board configuration assigned to these (em2860 +
saa7113) devices and it has been used for a long time (at least 4 years).
So unless we don't know the details about _all_ existing devices,
changes can always cause regressions.
That sucks, but it's the truth. :-(

So we have basically two choices:
a) be conservative and dot nothing to avoid regressions
b) speculate about unknown devices (possible configurations, quantity)
and pondering on the risks of changes

I personally tend to be conservative, but I'm not 100% sure if this is
The Right Thing (TM) to do in this case.


Regards,
Frank

> My two cents,
>
> Theodore Kilgore

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Wed, 20 Feb 2013 19:20:43 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> I personally tend to be conservative

Please stop playing games. You're the one accusing us of being conservative.

Let's just keep it as-is. I'm done with this thread.
Mauro

Re: Wrongly identified easycap em28xx

[Frank Schäfer]

Am 20.02.2013 20:12, schrieb Mauro Carvalho Chehab:
> Em Wed, 20 Feb 2013 19:20:43 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
>
>> I personally tend to be conservative
> Please stop playing games. You're the one accusing us of being conservative.

Bullshit.
I tried to do some brainstorming to find a way out of a dilemma, which
includes analyzing the pros and cons of _all_ solutions.
If that's "playing games" for you or simply to complex, I can't help
you, sorry.

> Let's just keep it as-is. I'm done with this thread.

Me too. Thanks for the fruitful discussion.

Best Regards,
Frank

> Mauro
>

Re: Wrongly identified easycap em28xx

[Mauro Carvalho Chehab]

Em Mon, 18 Feb 2013 22:25:01 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 18.02.2013 21:53, schrieb Mr Goldcove:
> > "Easy Cap DC-60++"
> > Wrongly identified as card 19 "EM2860/SAA711X Reference Design",
> > resulting in no audio.
> > Works perfectly when using card 64 "Easy Cap Capture DC-60"
> 
> Video inputs work fine, right ?
> Does this device has any buttons / LEDs ?
> 
> The driver doesn't handle devices with generic IDs very well.
> In this case we can conclude from the USB PID that the device has audio
> support (which is actually the only difference to board
> EM2860_BOARD_SAA711X_REFERENCE_DESIGN).
> But I would like to think twice about it, because this kind of changes
> has very a high potential to cause regressions for other boards...

While em28xx driver tries to do its best to detect, devices without
EEPROM will always have issues, as there are lots of similar devices
with small differences on how they were wired up.

That's why em28xx has the "card" modprobe parameter.

Ok, it likely makes sense to add an additional hint based on has_audio.

> 
> Regards,
> Frank
> 
> >
> > **Interim solution**
> > load module (before inserting the EasyCap. I'm having trouble if the
> > module is loaded/unloaded with different cards...)
> > modprobe em28xx card=64
> >   or
> > add "options em28xx card=64" to /etc/modprobe.d/local.conf

That is the right thing to do. It makes sense to have it documented at the
Wiki, in order to help others with similar boards.

Regards,
Mauro

> >
> > **hw info**
> > Bus 002 Device 005: ID eb1a:2861 eMPIA Technology, Inc.
> >
> > Chips:
> > Empia EM2860 P7JY8-011 201023-01AG
> > NXP SAA7113H
> > RMC ALC653 89G06K1 G909A

The driver could be detecting if Realtek alc653 is found, in order to
hint it as "EasyCap":

[ 5568.813055] em28xx #0: AC97 vendor ID = 0x414c4761

If I'm not mistaken, someone wrote at the ML that "EasyCap" is actually 
just a generic name used by some Chinese companies to indicate a video
capture USB device. The fact is that there are EasyCap devices using 
even completely different chipsets.

Cheers,
Mauro