Hi Tomasz, On Mon, Nov 18, 2019 at 08:32:35PM +0900, Tomasz Figa wrote: > On Sun, Oct 27, 2019 at 5:48 AM Laurent Pinchart > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > On Fri, Oct 25, 2019 at 03:29:49PM +0900, Tomasz Figa wrote: > > > On Wed, Oct 23, 2019 at 11:27 PM Pavel Machek <pavel@xxxxxx> wrote: > > > > > > > > Hi! > > > > > > > > > > I'm skeptical about adding now a property for a device that we don't > > > > > > support, because we -now- think it's a good idea. I might be wrong, > > > > > > but my assumption is that when someone will want to support an > > > > > > 'advanced' device, it's easy to add "movable" or whatever else to the > > > > > > list of accepted properties values. Am I wrong in assuming this? As > > > > > > long as "front" "back" and "external" will stay supported for backward > > > > > > DTB compatibility it should be fine, right ? > > > > > > > > > > The basic rule is that you should not define things unless you KNOW that > > > > > they will be needed. So when we actually see new devices for which > > > > > "front", "back" or "external" does not fit, then new names can be > > > > > created. > > > > > > > > > It's impossible to cover all situations since we can't predict the future. > > > > > The best we can do is to allow for future extensions. > > > > > > > > Those devices are already being sold, and yes, they are running linux > > > > (with some patches probably). > > > > > > > > I believe it would be better to specify "this camera is selfie -- > > > > takes pictures of the user" vs. "this is main camera -- takes pictures > > > > of what user is looking at". > > > > > > FWIW, Android and Chrome OS call those "user-facing" and > > > "world-facing" respectively. > > > > Isn't that equivalent to what Jacopo is proposing though ? If we define > > the orientation of the device relatively to its user (e.g. for all > > cellphone devices the front is defined as the side facing the user), and > > the location of the camera relative to the device, we get the same > > information. > > Yes, it is the same. Although having some consistency in the naming > isn't necessarily a bad idea, is it? :) > > That said, looks like the naming in the Android world isn't consistent > either. The high level Java/Kotlin API uses "front" and "back": > https://developer.android.com/reference/android/hardware/Camera.CameraInfo.html#summary > > How about making this property a string instead? It would make it more > readable in the dts and more expressive for some weird cases in the > future, e.g. "front+30deg", "vector" (and a vector could be given in > another property), etc. Why do you think this would be better ? We could provide macros if we want to have users expressing location in a more 'expressive' form than using a numerical id. I would avoid parsing strings to be honest. Would you be ok with this ? I don't see any core v4l2 header in include/dt-bindings/media/ but that could be a good occasion to add one ? > > Best regards, > Tomasz
Attachment:
signature.asc
Description: PGP signature
