On 10/11/2024 11:37, Ricardo Ribalda wrote: > On Sun, 10 Nov 2024 at 11:29, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> On 10/11/2024 11:02, Mauro Carvalho Chehab wrote: >>> Em Sat, 9 Nov 2024 17:29:54 +0100 >>> Ricardo Ribalda <ribalda@xxxxxxxxxxxx> escreveu: >>> >>>>> >>>>> I think that should sort the issue, assuming that 1. above holds true. >>>>> >>>>> One downside is that this stops UVC button presses from working when >>>>> not streaming. But userspace will typically only open the /dev/video# >>>>> node if it plans to stream anyways so there should not be much of >>>>> a difference wrt button press behavior. >>>> >>>> I do not personally use the button, but it is currently implemented as >>>> a standard HID device. >>> >>> IMO, controlling the privacy via evdev is the best approach then. There's >>> no need for a RW control neither at subdev or at device level. It could >>> make sense a Read only to allow apps to read, but still it shall be up to >>> the Kernel to protect the stream if the button is pressed. >>> >>>> Making it only work during streamon() might be >>>> a bit weird. >>>> I am afraid that if there is a button we should keep the current behaviour. >>> >>> Privacy matters only when streaming. IMO the Kernel check for it needs to >>> be done at DQBUF time and at read() calls, as one can enable/disable the >>> camera while doing videoconf calls. I do that a lot with app "soft" buttons, >>> and on devices that physically support cutting the video. >> >> We could add a vb2_s_privacy(bool privacy) function to vb2 to tell vb2 if the privacy >> mode is on. And if so, take action. E.g. calling QBUF/DQBUF would return a -EACCES error. >> >> That will ensure consistent behavior for all drivers that have a privacy function. > > I am not against adding a feature like this, but we still need a way > to notify userspace about a change of the privacy state when the user > presses it. > Controls are great for this. > >> >> Note that there are two types of privacy GPIO: one that triggers when a physical >> cover is moved, blocking the sensor, and one that is a button relying on software >> to stop streaming video. In the first case it is informative, but you can keep >> streaming. > > I am curious who implements a software privacy switch. I would > definitely use a physical cover in those devices. > > Chromebooks only support physical cover and hardware privacy switch. I > have not seen software privacy switches. I actually thought this discussion was about software privacy switched. I haven't seen any, but it wouldn't surprise me if there are webcams that do something like that. For proper privacy covers I don't think you need a vb2 implementation, even if you keep streaming you should just see black video, no need to refuse QBUF/DQBUF. Regards, Hans > >> >> Regards, >> >> Hans >> >>> >>> I don't trust myself privacy soft buttons, specially when handled in userspace, >>> so what I have are webcam covers (and a small stick glued at a laptop camera >>> that has a too small sensor for a webcam cover). I only remove the cover/stick >>> when I want to participate on videoconf with video enabled with the builtin >>> camera. >>> >>> Regards >>> >>> Thanks, >>> Mauro >>> >> > >
