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?
