Re: identifying camera sensor

Re: identifying camera sensor

[Hans Verkuil]

> 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

Re: identifying camera sensor

[Trent Piepho]

On Thu, 5 Mar 2009, Hans Verkuil wrote:
> 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'.

It would be one thing if there was just a possibility of them running out
in the distant future.  Rather, they'll run out before you even get started
on adding what's already available for digital cameras.  Focus distance,
exposure compensation, sensor manufacture and model, gravity sensors,
detailed gamma compensation curves, and so on.

>
> > 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

That's true.  While I think the control api is the best one for providing
ancillary data for images and sensor attributes, it's not perfect.  I'd add
a means to define the data type of a control/attribute and allow things
besides an s32.  Probably ASCIIZ strings and fix length byte arrays.

Also flags for:

constant vs volatile
  Constant attributes don't change, e.g. sensor manufacturer name.  Volatile
  ones can change, e.g. focus distance.

global vs per-input
  Global attributes are the same for the entire device, while per-input
  attributes are different for each input.  An API for querying the
  attribute for an input different the current might be nice, but I think
  it might be one of things that seem more important than they really are.

Frame syncable
  Frame syncable attributes (which only make sense for volatile attributes)
  can be synced to the exact frame they were measured at.  For instance,
  the the camera provides a focus distance value for software face
  tracking, it's important that the right focus distance be associated with
  the correct frame.  There should be an API by which one can request that
  the attribute be provided with each frame, maybe tacked onto the end of
  the v4l2_buffer structure.

> 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.

How would enum chips be different than enum controls?

Re: identifying camera sensor

[Trent Piepho]

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?

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.

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.

Re: identifying camera sensor

[Trent Piepho]

On Thu, 5 Mar 2009, Tuukka.O Toivonen wrote:
> 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@speakeasy.org>
> > 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 :(

Pretty much every single driver does this, so it's apparently not that
hard.

Another thing to consider, is that if the sensor has certain properties
that you want to know in user space, maybe the driver could provide those
properties drectly, instead of providing the sensor id and letting user
space app figure the properties from the id.

Re: identifying camera sensor

[Hans Verkuil]

> 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@speakeasy.org>
>> 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

Re: identifying camera sensor

[Tuukka.O Toivonen]

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@speakeasy.org>
> 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.

http://n2.nabble.com/-REVIEW--v4l2-debugging:-match-drivers-by-name-instead-of-the-deprecated-ID-td1681635.html

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 :-)


- Tuukka

Re: identifying camera sensor

[DongSoo(Nathaniel) Kim]

Hi tuukka,

Chip identification could be used for many other camera devices. Not
only for SMIA compatible sensors.
It could be used for generic camera devices I guess for any other
reasons, like checking chip version on factory assembly line in mass
production.

Something like G_CHIP_IDENT (as Hans mentioned) should be cool.

Cheers,

Nate

On Wed, Mar 4, 2009 at 11:12 PM, Tuukka.O Toivonen
<tuukka.o.toivonen@nokia.com> wrote:
> Hi,
>
> I am writing a generic driver for SMIA-compatible sensors.
> SMIA-sensors have registers containing:
>  u16 model_id
>  u16 revision_number
>  u8 manufacturer_id
> which could be used to detect the sensor.
> However, since the driver is generic, it is not interested
> of these values.
>
> Nevertheless, in some cases user space applications want
> to know the exact chip. For example, to get the highest
> possible image quality, user space application might capture
> an image and postprocess it using sensor-specific filtering
> algorithms (which don't belong into kernel driver).
>
> I am planning to export the chip identification information
> to user space using VIDIOC_DBG_G_CHIP_IDENT.
> Here's a sketch:
>  #define V4L2_IDENT_SMIA_BASE  (0x53 << 24)
> then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler:
>  struct v4l2_dbg_chip_ident id;
>  id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id << 16) | model_id;
>  id.revision = revision_number;
>
> Do you think this is acceptable?
>
> 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?
>
> I'll start writing a patch as soon as you let me know
> which would be the best alternative. Thanks!
>
> - Tuukka
> --
> 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
>



-- 
========================================================
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@gmail.com
          dongsoo45.kim@samsung.com
========================================================

Re: identifying camera sensor

[Hans Verkuil]

Hi Tuukka,

> Hi,
>
> I am writing a generic driver for SMIA-compatible sensors.
> SMIA-sensors have registers containing:
>   u16 model_id
>   u16 revision_number
>   u8 manufacturer_id
> which could be used to detect the sensor.
> However, since the driver is generic, it is not interested
> of these values.
>
> Nevertheless, in some cases user space applications want
> to know the exact chip. For example, to get the highest
> possible image quality, user space application might capture
> an image and postprocess it using sensor-specific filtering
> algorithms (which don't belong into kernel driver).
>
> I am planning to export the chip identification information
> to user space using VIDIOC_DBG_G_CHIP_IDENT.
> Here's a sketch:
>   #define V4L2_IDENT_SMIA_BASE	(0x53 << 24)
> then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler:
>   struct v4l2_dbg_chip_ident id;
>   id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id << 16) | model_id;
>   id.revision = revision_number;
>
> Do you think this is acceptable?

This ioctl is meant for debugging only. It's API can change without notice
(hence the 'DBG' part in the name and the warnings in the v4l2 spec). In
fact, it did change recently.

The only application using it is v4l2-dbg, which is a tool that allows you
to read and write registers on the fly. Very useful for debugging.

It is also used internally in the kernel if the adapter driver needs to do
different things depending on the actual chip used.

So it is *not* acceptable to use this API in a generic application (i.e.
an app that can be used for all sorts of different hardware). However, on
an embedded system where you control the environment I have no objection
if someone uses it in a custom application. They should be aware though
that this API can change in a future kernel. But since they control the
kernel version as well that shouldn't pose a problem.

> 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 :-)

> I'll start writing a patch as soon as you let me know
> which would be the best alternative. Thanks!

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.

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

identifying camera sensor

[Tuukka.O Toivonen]

Hi,

I am writing a generic driver for SMIA-compatible sensors.
SMIA-sensors have registers containing:
  u16 model_id
  u16 revision_number
  u8 manufacturer_id
which could be used to detect the sensor.
However, since the driver is generic, it is not interested
of these values.

Nevertheless, in some cases user space applications want
to know the exact chip. For example, to get the highest
possible image quality, user space application might capture
an image and postprocess it using sensor-specific filtering
algorithms (which don't belong into kernel driver).

I am planning to export the chip identification information
to user space using VIDIOC_DBG_G_CHIP_IDENT.
Here's a sketch:
  #define V4L2_IDENT_SMIA_BASE	(0x53 << 24)
then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler:
  struct v4l2_dbg_chip_ident id;
  id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id << 16) | model_id;
  id.revision = revision_number;

Do you think this is acceptable?

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?

I'll start writing a patch as soon as you let me know
which would be the best alternative. Thanks!

- Tuukka