On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote: Hello Theo,
> 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? >From what I can tell, there are two ways to control a uvideo device: 1) The "semi-persistent" state changes that video(1) can make that affects subsequent apps which access the device. My patch simply makes those state changes possible from the command-line instead of forcing the user to open a video and hold down keys until they reach the desired state. In other words, it doesn't change how you control the device: "-c reset" is equivalent to running video(1) and pressing "r", for example. 2) Control via a loopback device. For example, on Windows, Logitech allow you to change controls in their app where you can see video; they then expose a second internal device which other apps can use; I think controls are reset when the Logitech app is closed. On Linux I believe v4l2-ctl works as video(1) does (semi-persistent state changes) but Linux also has video loopback devices. Presumably they could do something similar to the Logitech Windows app, but I don't know if they do so or not. Unless we develop a loopback facility (or, perhaps, some sort of uvideo daemon roughly equivalent to sndiod), I don't think we have much choice but to continue with the semi-persistent state changes that video(1) has always been capable of. It is a bit icky, but it's the only way, for example, to change a webcam's brightness before taking a video call in a web browser. Laurie
