Re: [RFC] How to pass camera Orientation to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to userspace, so there is no way to clear the bits to make the camera do something.
First, I'd like to say I agree with most that the installed orientation of
the camera sensor really is a different concept than the current value of a
gravity sensor.  It's not necessary, and maybe not even desirable, to
handle them in the same way.

I do not see the advantage of using reserved bits instead of controls.

The are a limited number of reserved bits.  In some structures there are
only a few left.  They will run out.  Then what?  Packing non-standard
sensor attributes and camera sensor meta-data into a few reserved bits is
not a sustainable policy.

Controls on the other card are not limited and won't run out.

Yes but these things are *not* controls, end of discussion. The control API is
for controls, not to stuff all kind of cruft in.

All kind of cruft belongs in the reserved bits of whatever field it can be
stuffed in?

Not whatever field, these are input properties which happen to also be pretty binary so putting them in the input flags field makes plenty of sense.

What is the difference?  Why does it matter?  Performance?  Maintenance?
Is there something that's not possible?  I do not find "end of discussion"
to be a very convincing argument.

Well they are not controls, that is the difference, the control interface is for controls (and only for controls, end of discussion if you ask me). These are not controls but properties, they do not have a default min and max value, they have only one *unchanging* value, there is nothing the application can control / change. It has been suggested to make them readonly, but that does not fix the ugliness. A proper written v4l2 application will enumerate all the controls, and then the user will see a grayed out control saying: "your cam is upside down" what is there to control ? will this be a grayed out slider? or a grayed out checkbox "your cam is upside down", or maybe a not grayed out dropdown: where the user can select: "my sensor is upside down", "I deny my sensor is upside down", "I don't care my sensor is upside down", "WTF is this doing in my webcam control panel?", "nwod edispu si rosnes yM"

Do you know I have an idea, lets get rid of the S2 API for DVB and put all that in controls too. Oh, and think like standards for video formats, surely that can be a control too, and ... and, ...

Yes we can stuff almost anything in a control, that does not make it a good idea.

Regards,

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux