On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
> Matthieu Herrb <[email protected]> wrote:
>
> > On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > > Marcus Glocker <[email protected]> wrote:
> > >
> > > > Instead of introducing the CLI parameter controls in video(1), we could
> > > > introduce videoctl(1) in base, same as we have with audioctl(1). This
> > > > also gives us the possibility to only display the current video
> > > > parameters.
> > >
> > > I must have missed something. Why does it need to be a seperate comment.
> > > Won't this produce confusion? Why can video do this?
> > >
> > > Is it really correct for the video hardware to have persistant settings?
> > > Would it not be better if the required mode was always commanded when
> > > a video is being recorded?
> >
> > I've not followed UVC hardware too closely; it seems that some of the
> > cameras are always fully automatically adjusting their parameters,
> > while others allow for manual setting that remains between device
> > open().
> >
> > And some of the controls are not available when video(4) is used from
> > a browser (for conferencing).
> >
> > On a 2nd thought having that integrated with video(1) allows to
> > control the values with visual feedback so it makes sense to keep only
> > one program. But ihmo it would be more user friendly if the command
> > line syntax was more regular with audio or wscons control programs.
>
> My primary concern is about a user changing settings which then persist
> past close.
>
> Upon re-open, how do they know what mode they are in?
>
> I understand the default mode for a camera might not be nice. But at
> least it is a default. If the previous use of the camera put it into
> a nasty mode, does this mean all new users must first force default?
>
> Now you don't know what mode it is in. As a result, you must *always*
> demand change into a specific mode. Rather than making things simpler,
> doesn't use of a camera become potentially more complicated?
OK - Lets put aside the audioctl(1) discussion. Maybe the idea isn't
that good than I initially thought and would indeed over-complicate
things.
Regarding the current behavior of video(1) for the default controls;
When you change the controls today through the video(1) keys, they are
already sticky, since the reset control function only can be called
through the 'r' key-press. If we want to go for a default mode on close,
of course that function could be easily copied to the video(1) closing
routine.
The idea of the patch on the other side was to enable somebody to
easily set his preferred controls, e.g. through a script. At the
moment if you want to set your preferred controls on cam start-up,
that's only possible by the key-presses which is odd obviously if you
need to change a couple of controls every time by pressing keys. How
many people would finally find that an useful feature is another
question I guess.
I have no strong opinion about the line syntax, but I agree keeping it
similar to other commands would be good. E.g. adapting video(1) to
the audioctl(1) syntax and doing something like
$ video brightness=200 contrast=150
could be an option - If we want to follow this feature at all.
