> On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote: >> > Alternatively, VIDIOC_QUERYCAP could be used to identify the sensor. >> > Would it make more sense if it would return something like >> > capability.card: `omap3/smia-sensor-12-1234-5678//' >> > where 12 would be manufacturer_id, 1234 model_id, and >> > 5678 revision_number? >> >> Yuck :-) > > Agreed :) > > Also, if there are many slaves, the length of the capability.card > field is not sufficient. > > From: Trent Piepho <xyzzy@xxxxxxxxxxxxx> >> You could always try to decode the manufacturer name and maybe even the >> model name. After all, pretty much every other driver does this. > > That would be possible, but the driver would then need a device name table > which would need to be modified whenever a new chip comes up :( > > On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote: >> G_CHIP_IDENT is probably the way to go, provided you are aware of the >> limitations of this ioctl. Should this be a problem, then we need to >> think >> of a better solution. > > Could you tell me what limitations? > > I thought about that ioctl initially, but then read that it is going > to be removed, that's why abandoned it. The limitation is that it's API might change from one kernel version to another. It's not going to be removed. http://n2.nabble.com/-REVIEW--v4l2-debugging:-match-drivers-by-name-instead-of-the-deprecated-ID-td1681635.html That's the API change :-) This change is already in 2.6.29. > But if you say it's a good way, then I'll go that way. > The intention is to get the SMIA driver included into official kernel, > so I'd prefer a method which allows that :-) Using DBG_G_CHIP_IDENT is the quick way of doing things, but it is by definition an API that might change in the future (although I hope that doesn't happen anytime soon). If you want something stable, then we need to come up with an alternative. ENUMINPUT is probably a better solution: you can say something like "Camera 1 (sensor1)", "Camera 2 (sensor2)". It remains a bit of a hack, though. The problem is that DBG_G_CHIP_IDENT is really the only ioctl that can do what you want, but it is meant for internal use only. Perhaps this calls for an ENUM_CHIPS ioctl that calls G_CHIP_IDENT internally. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
