lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190901172457.GC1047@bug>
Date:   Sun, 1 Sep 2019 19:24:57 +0200
From:   Pavel Machek <pavel@....cz>
To:     Hans Verkuil <hverkuil-cisco@...all.nl>
Cc:     Jacopo Mondi <jacopo@...ndi.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        "open list:MEDIA INPUT INFRASTRUCTURE (V4L/DVB)" 
        <linux-media@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 2/5] media: v4l2-ctrl: Document V4L2_CID_LOCATION

Hi!

> >>>>> @@ -510,6 +510,29 @@ enum v4l2_scene_mode -
> >>>>>      value down. A value of zero stops the motion if one is in progress
> >>>>>      and has no effect otherwise.
> >>>>>
> >>>>> +``V4L2_CID_LOCATION (integer)``
> >>>>
> >>>> Maybe V4L2_CID_CAMERA_SENSOR_LOCATION ? Same for the values below.
> >>>
> >>> Probably a better name, if a bit long. But we might need other location
> >>> controls in the future (e.g. flash location), so CID_LOCATION is just too
> >>> generic.
> >>
> > 
> > Thanks for the feedback.
> > 
> >> Note that the location defines themselves can most likely be used with any
> >> LOCATION control, so V4L2_LOCATION_FRONT would be fine with any control.
> >>
> > 
> > What do you think instead of the control type? Would a single integer
> > control do or an integer menu one would be better? I see merit in both
> > proposals actually...
> 
> Single integer. It's read-only, so it just reports the location.
> 
> It would be different if this was a writable control: then you need to
> know which locations are possible to set, and that requires a menu type.
> 
> But it doesn't make sense to set the location from software. However, the
> location might change as a result of other changes: e.g. if the camera
> has motor control of the tilt and the tilt changes from forward facing to
> downward facing, then the driver might change the location from FRONT
> to DOWN. A convoluted example perhaps, but this is just brainstorming.

There are phones with exactly such camera setup. And yes, it makes sense to be writable
in that case, as software can move the camera in such case.

										Pavel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ