From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
Mr Goldcove <goldcove@gmail.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Wrongly identified easycap em28xx
Date: Wed, 20 Feb 2013 19:15:37 +0100 [thread overview]
Message-ID: <512512C9.5070604@googlemail.com> (raw)
In-Reply-To: <20130219194208.18210419@redhat.com>
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
next prev parent reply other threads:[~2013-02-20 18:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=512512C9.5070604@googlemail.com \
--to=fschaefer.oss@googlemail.com \
--cc=dheitmueller@kernellabs.com \
--cc=goldcove@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).