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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
