On Sun, 22 Feb 2009, Hans de Goede wrote:
kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:
<snip>
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it is
relevant to point out that flags can be toggled. Here is what I mean:
Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies VFLIP
and 10 signifies HFLIP.
Then for an "ordinary" camera in ordinary position these are initialized as
00. If the "ordinary" camera is turned in some funny way (and it is
possible to know that) then one or both of these flags gets turned off.
But if it is a "funny" camera like some of the SQ905s the initial values
are 1 and 1, because the sensor is in fact mounted upside down. Now,
suppose that there is some camera in the future which, just like this, has
the sensor upside down, and suppose that said hypothetical camera also has
the ability to "know" that it has been turned over so what was upside down
is now right side up. Well, all that one has to do is to flip the two bits
from whatever they were to have instead the opposite values!
Observe that this would take care of the orientation problem both for
cameras which had the sensor mounted right in the first place, and for
cameras which had the sensor mounted wrong in the first place. Just use the
same two bits to describe the sensor orientation, and if there is any
reason (based upon some ability to know that the camera orientation is now
different) that the orientation should change, then just flip the bits as
appropriate.
Then it would be the job of the support module to provide proper initial
values only for these bits, and everything else could be done later on, in
userspace.
Theodore Kilgore
Theodore,
We want to be able to differentiate between a cam which has its sensor
mounted upside down, and a cam which can be pivotted and happens to be upside
down at the moment, in case of any upside down mounted sensor, we will always
want to compentsate, in case of a pivotting camera wether we compensate or
not could be a user preference.
So in you example of an upside down mounted sensor in a pivotting encasing
and the encasing is pivotted 180 degrees we would have the hflip and vflip
bits set for sensor orientation and we would have the pivotted 180 degrees
bit set. If the user has choosen to compensate for pivotting the default, we
would do nothing. But it is important to be able to differentiate between the
2.
Hans,
I am not sure if we are talking past each other, or what. But I was
pointing out that the initial values of two bits can indicate the
"default" orientation of the sensor, and this can be done permanently in
the module, which transmits the initial setting of those two bits to
anything up the line which is interested or curious to know those initial
values. The information in those two bits will definitely tell whether the
sensor is mounted upside down in the camera. For example, if it is mounted
upside down, then they are both set in the module to "on" and exported
therefrom. But if the sensor is mounted correctly, then both of them are
set to "off" and similarly exported.
Now if any application for any reason (such as "knowing" that the
camera is upside down or is pointing in the opposite direction, or into a
mirror) wants to change the defaults, all it has to do is to toggle the
bits.
But, hmmm. Perhaps there is the question about how the app "knows" that
the camera is upside down or is pointed in another direction. If the
camera has a gyroscope inside, for example, then it could be the camera
which needs to tell to the app about the current orientation, or else the
app would not have any way to know ... Is this the problem, then? For that
kind of thing, one might need more than two bits in order to pass the
needed information.
Incidentally, I obviously agree about the need to pass the initial sensor
orientation. So anything I say about this should be taken in that context.
Theodore Kilgore
--
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
