Message-ID: <ef6c4737-44f6-472b-8130-fe58f7930c4a@xs4all.nl>
Date: Sun, 10 Nov 2024 11:47:56 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
 Hans de Goede <hdegoede@...hat.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, Yunke Cao <yunkec@...omium.org>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a
 subdevice

On 10/11/2024 11:37, Ricardo Ribalda wrote:
> On Sun, 10 Nov 2024 at 11:29, Hans Verkuil <hverkuil@...all.nl> wrote:
>>
>> On 10/11/2024 11:02, Mauro Carvalho Chehab wrote:
>>> Em Sat, 9 Nov 2024 17:29:54 +0100
>>> Ricardo Ribalda <ribalda@...omium.org> 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
>>>
>>
> 
> 

Powered by blists - more mailing lists