On Fri, Nov 22, 2019 at 1:00 AM Jacopo Mondi <jacopo@xxxxxxxxxx> wrote: > > 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 ? As an afterthought, there is no flexibility issue even with an enum. We could still have the "location" property set to the enum corresponding to front and then if we need to rotate it relative to that position we could define another property called "rotation". Feel free to add my Acked-by. Best regards, Tomasz
