* Wrongly identified easycap em28xx
@ 2013-02-18 20:53 Mr Goldcove
2013-02-18 21:25 ` Frank Schäfer
0 siblings, 1 reply; 22+ messages in thread
From: Mr Goldcove @ 2013-02-18 20:53 UTC (permalink / raw)
To: V4L Mailing List
"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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-18 20:53 Wrongly identified easycap em28xx Mr Goldcove
@ 2013-02-18 21:25 ` Frank Schäfer
2013-02-18 22:36 ` Mr Goldcove
2013-02-19 13:06 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 22+ messages in thread
From: Frank Schäfer @ 2013-02-18 21:25 UTC (permalink / raw)
To: Mr Goldcove; +Cc: Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-18 21:25 ` Frank Schäfer
@ 2013-02-18 22:36 ` Mr Goldcove
2013-02-19 16:02 ` Frank Schäfer
2013-02-19 16:47 ` Frank Schäfer
2013-02-19 13:06 ` Mauro Carvalho Chehab
1 sibling, 2 replies; 22+ messages in thread
From: Mr Goldcove @ 2013-02-18 22:36 UTC (permalink / raw)
To: Frank Schäfer; +Cc: V4L Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-18 21:25 ` Frank Schäfer
2013-02-18 22:36 ` Mr Goldcove
@ 2013-02-19 13:06 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-19 13:06 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-18 22:36 ` Mr Goldcove
@ 2013-02-19 16:02 ` Frank Schäfer
2013-02-19 16:51 ` Mr Goldcove
2013-02-19 16:47 ` Frank Schäfer
1 sibling, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-19 16:02 UTC (permalink / raw)
To: Mr Goldcove; +Cc: Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-18 22:36 ` Mr Goldcove
2013-02-19 16:02 ` Frank Schäfer
@ 2013-02-19 16:47 ` Frank Schäfer
2013-02-19 18:30 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-19 16:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 16:02 ` Frank Schäfer
@ 2013-02-19 16:51 ` Mr Goldcove
0 siblings, 0 replies; 22+ messages in thread
From: Mr Goldcove @ 2013-02-19 16:51 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Linux Media Mailing List
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)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 16:47 ` Frank Schäfer
@ 2013-02-19 18:30 ` Mauro Carvalho Chehab
2013-02-19 18:45 ` Frank Schäfer
0 siblings, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-19 18:30 UTC (permalink / raw)
To: Frank Schäfer
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 18:30 ` Mauro Carvalho Chehab
@ 2013-02-19 18:45 ` Frank Schäfer
2013-02-19 18:53 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-19 18:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 18:45 ` Frank Schäfer
@ 2013-02-19 18:53 ` Mauro Carvalho Chehab
2013-02-19 19:45 ` Frank Schäfer
0 siblings, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-19 18:53 UTC (permalink / raw)
To: Frank Schäfer
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 18:53 ` Mauro Carvalho Chehab
@ 2013-02-19 19:45 ` Frank Schäfer
2013-02-19 20:03 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-19 19:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 19:45 ` Frank Schäfer
@ 2013-02-19 20:03 ` Mauro Carvalho Chehab
2013-02-19 22:14 ` Frank Schäfer
2013-02-20 5:09 ` Theodore Kilgore
0 siblings, 2 replies; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-19 20:03 UTC (permalink / raw)
To: Frank Schäfer
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 20:03 ` Mauro Carvalho Chehab
@ 2013-02-19 22:14 ` Frank Schäfer
2013-02-19 22:42 ` Mauro Carvalho Chehab
2013-02-20 5:09 ` Theodore Kilgore
1 sibling, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-19 22:14 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 22:14 ` Frank Schäfer
@ 2013-02-19 22:42 ` Mauro Carvalho Chehab
2013-02-20 18:15 ` Frank Schäfer
0 siblings, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-19 22:42 UTC (permalink / raw)
To: Frank Schäfer
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 20:03 ` Mauro Carvalho Chehab
2013-02-19 22:14 ` Frank Schäfer
@ 2013-02-20 5:09 ` Theodore Kilgore
2013-02-20 10:49 ` Andy Walls
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Theodore Kilgore @ 2013-02-20 5:09 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Frank Schäfer, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 5:09 ` Theodore Kilgore
@ 2013-02-20 10:49 ` Andy Walls
2013-02-20 10:51 ` Mauro Carvalho Chehab
2013-02-20 18:20 ` Frank Schäfer
2 siblings, 0 replies; 22+ messages in thread
From: Andy Walls @ 2013-02-20 10:49 UTC (permalink / raw)
To: Theodore Kilgore, Mauro Carvalho Chehab
Cc: Frank Schäfer, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 5:09 ` Theodore Kilgore
2013-02-20 10:49 ` Andy Walls
@ 2013-02-20 10:51 ` Mauro Carvalho Chehab
2013-02-20 18:23 ` Frank Schäfer
2013-02-20 18:20 ` Frank Schäfer
2 siblings, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-20 10:51 UTC (permalink / raw)
To: Theodore Kilgore
Cc: Frank Schäfer, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-19 22:42 ` Mauro Carvalho Chehab
@ 2013-02-20 18:15 ` Frank Schäfer
0 siblings, 0 replies; 22+ messages in thread
From: Frank Schäfer @ 2013-02-20 18:15 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Mr Goldcove, Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 5:09 ` Theodore Kilgore
2013-02-20 10:49 ` Andy Walls
2013-02-20 10:51 ` Mauro Carvalho Chehab
@ 2013-02-20 18:20 ` Frank Schäfer
2013-02-20 19:12 ` Mauro Carvalho Chehab
2 siblings, 1 reply; 22+ messages in thread
From: Frank Schäfer @ 2013-02-20 18:20 UTC (permalink / raw)
To: Theodore Kilgore
Cc: Mauro Carvalho Chehab, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 10:51 ` Mauro Carvalho Chehab
@ 2013-02-20 18:23 ` Frank Schäfer
0 siblings, 0 replies; 22+ messages in thread
From: Frank Schäfer @ 2013-02-20 18:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Theodore Kilgore, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
<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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 18:20 ` Frank Schäfer
@ 2013-02-20 19:12 ` Mauro Carvalho Chehab
2013-02-21 18:39 ` Frank Schäfer
0 siblings, 1 reply; 22+ messages in thread
From: Mauro Carvalho Chehab @ 2013-02-20 19:12 UTC (permalink / raw)
To: Frank Schäfer
Cc: Theodore Kilgore, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Wrongly identified easycap em28xx
2013-02-20 19:12 ` Mauro Carvalho Chehab
@ 2013-02-21 18:39 ` Frank Schäfer
0 siblings, 0 replies; 22+ messages in thread
From: Frank Schäfer @ 2013-02-21 18:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Theodore Kilgore, Devin Heitmueller, Mr Goldcove,
Linux Media Mailing List
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
>
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-02-21 18:38 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-18 20:53 Wrongly identified easycap em28xx Mr Goldcove
2013-02-18 21:25 ` Frank Schäfer
2013-02-18 22:36 ` Mr Goldcove
2013-02-19 16:02 ` Frank Schäfer
2013-02-19 16:51 ` Mr Goldcove
2013-02-19 16:47 ` Frank Schäfer
2013-02-19 18:30 ` Mauro Carvalho Chehab
2013-02-19 18:45 ` Frank Schäfer
2013-02-19 18:53 ` Mauro Carvalho Chehab
2013-02-19 19:45 ` Frank Schäfer
2013-02-19 20:03 ` Mauro Carvalho Chehab
2013-02-19 22:14 ` Frank Schäfer
2013-02-19 22:42 ` Mauro Carvalho Chehab
2013-02-20 18:15 ` Frank Schäfer
2013-02-20 5:09 ` Theodore Kilgore
2013-02-20 10:49 ` Andy Walls
2013-02-20 10:51 ` Mauro Carvalho Chehab
2013-02-20 18:23 ` Frank Schäfer
2013-02-20 18:20 ` Frank Schäfer
2013-02-20 19:12 ` Mauro Carvalho Chehab
2013-02-21 18:39 ` Frank Schäfer
2013-02-19 13:06 ` Mauro Carvalho Chehab
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.