On Mon, 23 Feb 2009, Adam Baker wrote:
On Monday 23 February 2009, Mauro Carvalho Chehab wrote:
On Sat, 21 Feb 2009 12:53:57 +0100
Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Me too.
<big snip>
The interest in detecting if a driver provides this informnation is to
allow libv4l to know when it should use the driver provided information
and when it should use its internal table (which needs to be retained
for backward compatibility). With no detection capability the driver
provided info should be ignored for USB IDs in the built in table.
<snip>
Ok, this is nothing that kernel needs to handle, but, at userspace, we need
to have a file where the user could edit and store the camera position, to
override whatever we have in kernel.
Unfortunately what that doesn't address is the problem that first started this
discussion. A camera where the orientation information is contained in the
USB messages from the camera so the driver is the only thing that can
reasonably access it.
Alas, this is so true. What started the entire discussion about passing
the info about sensor orientation is a set of cameras all of which have
the same Vendor:Product ID but require different handling of the data
(vflip and hflip, or just vflip) depending upon information which can only
be obtained by communication with the camera, *not* by just knowing its
Vendor:Product ID.
Therefore, it is a little bit disheartening to see discussions -- again --
which come back to some kind of "internal table" in V4L, or which come
back to things like "have a file where the user could edit and store the
camera position, to override whatever we have in kernel."
Repeating the obvious, which apparently still needs to be repeated because
not all of the participants in the discussion "get it":
1. The "internal table" in V4L could not handle this problem, because the
internal table would be based upon what information? The USB
Vendor:Product number? For that matter, no other table could work,
either. Well, actually, a table could work. It would have to be inside the
module supporting the camera, and the matter of which table entry
corresponds to what camera would have to be settled by passing a USB
command to the camera and then parsing the camera's response. So now the
question is how to get the information out of the module, which can only
be collected and analysed inside the module.
2. The "have a file where the user could edit" idea may seem attractive to
some, because it shoves the whole problem of agreeing on the appropriate
way to get needed information out of a kernel module and into userspace
onto someone not present during the current discussion, the user. However,
this is not a solution, and thinking about it just a little bit ought to
make that totally obvious. This is a strongly worded statement, so I will
proceed to explain why the matter is so obvious.
Let us assume the very best, and assume that every app which is V4L
conformant has a "one time" initialization step and creates a directory
$HOME/.app containing stored settings. So we might have a file called
$HOME/.app/sq905. This file gets automatically written when the hapless
user hooks up his sq905 camera the first time, and has to go through a
choice routine to decide which side of the frame is up and which side is
to the left and to the right. One could even take serious steps to make
this otherwise unnecessary and silly sequence to be as really nice and
"user friendly" as it could possibly be, and set this all up to be done
with a sequence of mouse clicks and then the file, very kindly, gets
written automatically. Those of you who are thinking that this "file a
user could edit" is the way to go are, presumably, thinking along these
lines. Well there are at least four things which are obviously wrong with
this "solution":
2.1. The user is forced to deal with something which the user should not
even have to confront. The user is called upon to remedy an omission and a
deficiency which was ignored at a lower level, because a bunch of
developers could not come together on a reasonable course of action. Well,
some don't like to see this one, so there are three more reasons.
2.2 Every camera is going to require a file for itself in $HOME/.app even
if there is nothing that the user needs to do. Many of the supported
cameras need nothing of the kind, so this would be kind of silly.
2.3 The user has two apps for dealing with webcams. So now the user needs
to have another directory called $HOME/.app2 with similar files in it?
2.4 (and this one is the worst of all) The user has two cameras which are
both powered by the same kernel module, and the two cameras need two
different things done. Now what??? Both cameras can not simultaneously
have a valid entry in $HOME/.app/sq905 which tells what to do with the
data out of the camera. Because what is right for one of them is wrong for
the other. Further to add to this, one of the tests which was run on this
very module was to see if it will run two of the same kind of camera
simultaneously. It passed the test. Now someone wants the data to be
right-side up from both cameras, and correctly oriented left-to
right. Is that an unreasonable desire on the part of a user? Of
course not. Again, now what????
There is no way out of this series of dilemmas and absurdities with the
"file a user could edit" approach. None.
So, please, could we get serious and actually come up with a reasonable
solution? To put the matter completely in perspective, the support for the
affected set of devices is otherwise quite complete, and the only thing
remaining is to come up with a reasonable solution, which would provide a
pleasing experience to users.
Theodore Kilgore
--
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
