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? Until the bits run out and then it belongs where? 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. -- 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
