> On Thu, 5 Mar 2009, Hans Verkuil wrote:
>>
>> 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.
>
> Maybe use some of the reserved bits in v4l2_input to show not only the
> sensor orientation, but also manufacturer, model, and revision? I wonder
> if there are enough bits for that?
I was just brainstorming, seeing what options there are. As I said, it's a
hack so it is not a very good option.
> How does this discussion go? I point out that using reserved bits is not
> sustainable, does not allow enumeration of supplied properties, and
> provides no meta-data for the self-documentation of those properties. The
> control interface provides all these things. Then you point out that
> these
> aren't "controls" and say end of discussion.
Reserved bits are there for a reason. If a particular bit of information
it a perfect match with for that API, then it seems utterly pointless to
me to decide not to use them 'just because we might run out in the
future'.
> Though if one had considered allowing the control api to be used to
> provide
> sensor properties, then the solution to this problem would now be quite
> simple and obvious.
In this case you want to have device names. While not impossible, it is
very hard to pass strings over the control api. Lots of issues with 32-64
bit compatibility and copying to/from user space. Also, in this case the
control API is NOT a good match, since this isn't a single piece of data,
instead you can have multiple sensor devices or other video enhancement
devices that an application might need to know about. Which is why my last
brainstorm suggestion was an ENUM_CHIPS ioctl.
Note: the reason we want names instead of IDs is that the kernel is moving
away from hardcoded IDs to strings in general. It's the same reason why
the i2c core is moving away from driver IDs and adapter IDs.
But the big question is whether the application really needs to know the
chip in question, or needs to know capabilities of the device. The made a
good point there in your previous email. I'm not comfortable exporting
information about internal devices unless there is a very good reason for
it.
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
