On Tue, 24 Feb 2009, kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
<big snip>
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905 cameras are not "notebook webcams." They are cheap,
consumer entry level dual-mode cameras. They can be used as hand-held still
cameras, to shoot still photos, and they can also be used as webcams. When
sold, they usually came with some kind of mounting device that could hold
them rigidly for webcam use. There are lots of similar cameras. Mercifully,
not all of those others have the problems of the sq905, which have led to
the present impasse.
If
you think about non-notebook webcams [1] or about security cams, you'll
see that the only way for you to have the flipping information is inside
some userspace file.
However, there are obvious differences. For those cameras the question might
well come up about how to control the movement of the camera, or, at least,
to be aware of which way the camera is pointing. For these, the topic is an
inherent property of the particular model of the camera -- or a defect, if
someone wants to say so. Since the property is not determined by USB number,
it is inherently impossible outside of the module to create a table which
contains the needed information.
My intention here was to re-focus attention on the original problem which
brought up the current discussion, and to that end the problem must be
clearly understood. To have the flipping information inside some userspace
file might solve some other problem and may be a generally very good idea.
But it will not, can not, and never will be able to solve this problem.
For example, I have here one video input bttv board with 16 cameras,
connected on 4 bttv chips. I have also a Pelco camera, that has just one
support socket. Depending on the place you mount it, the camera has to be
rotated by 180 degrees. It can also be useful to mount it rotated by 90
degrees.
Good. So one needs external controls and userspace tools. Did I ever say
that such things should never be done? No. All I said was that there is a
problem, presently on the table, and those kinds of things are not, can not
be, never were, and never will be solutions for _this_ problem.
After mounting the cameras, no matter what apps you are using (a
streaming video app to broadcast it via internet, a security app, etc),
the rotation
information for that input, on that particular PCI, bus won't change.
As we've standardized the VIDIOC_QUERYCAP bus_info, now, the information
for the camera at input 3 of bttv hardware at PCI addres 03:00.3 is
unique. It is also unique the same information for a notebook mounted
webcam (since the USB bus ID won't change for that devices).
Errrm... Again, the cameras in question here are not notebook mounted
webcams.
So, if we standardize where this information is stored, for example, at
/etc/libv4l and/or at ~/.libv4lrc, and let libv4l handle such info, this
will be something consistent for all applications using libv4l. Other
apps that might not want to trust on libv4l can also read the info at the
same file.
Sorry, this will not work here. It may solve some other problem, but not
this problem. Or, if one wants to "store" the information there, I don't
care, really, but then there needs to be a way to get the information from
the module, where it is, and get written into said table, which is where you
want it, and this needs to happen every time an sq905 camera gets plugged in
-- without pestering the user about the matter every time that such a camera
gets hooked up.
Comparison: I have tossed a coin. Is it going to come up heads? Or tails? It
is possible to know which, because the coin has been tossed. It would not
even be cheating to look at it, or allow someone who did look at it, to pass
to us the information. But we are not going to look, and if someone tells us
we will not listen because we have not agreed on what language to use for
communication. Instead, we will put a guess about the outcome into a table.
We will make it a nice table, which can be revised using nice GUI tools, so
it is easy for the user. So if our guess is wrong let the user fix it. Then
next time we toss the coin the table entry will be right because either it
was right before, or now someone fixed it???
So, I really think that this should be part of the approach.
I was not even addressing what should or should not be part of the approach
to some other problems. My point was that such discussion is not germane to
the problem of how to pass on the correct orientation of the sensor, for the
sq905 cameras. There are lots of other problems out there to solve. No
denying that.
Also an overview is often very helpful. Also trying to visualize what might
be needed in the future is helpful. All of this can be extremely helpful.
But not everyone can see or imagine every possible thing. For example, it
seems that some of the best minds in the business are stunned when
confronted with the fact that some manufacturer of cheap electronics in
Taiwan has produced a lot of mass-market cameras with the sensors turned
upside down, along with some other cameras having the same USB ID with
different sensors, which act a bit differently. Clearly, if such a thing
happened once it can happen again. So how to deal with such a
problem? Something similar or worse will surely come up again.
I agree that we should have a way to get a hint about a camera rotation,
if this is somehow provided by reading at the hardware.
[1] Normal webcams can be mounted on some hardware and have some
orientations that would be different than expected. I've seen this before
on some PC-based harware where the camera is enclosed inside the clause,
like on Automatic Transfer Machines. Also, the user may want to use the
camera on an inverted position, to make easy to fix it somewhere.
Again, these are in fact separate issues. The fundamental issue required for
supporting the sq905 cameras is that an agreed-upon method must exist by
which precisely two pieces of information can be passed along by the module.
Which of the two pieces of information is relevant and needs to be sent
along is, alas, only known from within the module. That is the backdrop for
the entire discussion. As far as I know, this thread would not exist if that
need had not come up. These two pieces of information are, precisely, "frame
data requires flipping across a horizontal axis unless camera is upside
down" and "frame data requires flipping across a vertical axis unless camera
is held up to a mirror"
So, what do these two deep questions, which confound the assembled wisdom of
an entire list of Linux video developers, have to do with tables in
userspace? None that I can see, unless someone wants to provide a mechanism
for the information, having been collected in the module, to be available to
the table in userspace.
I'm not saying that userspace tables would solve all problems. I'm just
saying that this should be part of the solution.
For sure we need to have a way for retrieving this information for devices
like the sq905 cameras, where the information can't be currently be
determined by userspace.
In the case of sq905, this information is static, right? If so, IMO, the
better approach is to use a flag at the v4l2_input, as already discussed
in this thread.
--
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
mchehab@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
