linux-kernel - Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a subdevice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f2638853-6c0a-49ee-9a80-28fb774cc678@redhat.com>
Date: Mon, 25 Nov 2024 13:31:49 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Ricardo Ribalda <ribalda@...omium.org>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: 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>,
 Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a
 subdevice

Hi Ricardo,

On 10-Nov-24 5:04 PM, Ricardo Ribalda wrote:
> On Sun, 10 Nov 2024 at 16:14, Laurent Pinchart
> <laurent.pinchart@...asonboard.com> wrote:

<snip>

>>> Can we start powering up the device during try/set fmt and then
>>> implement the format caching as an improvement?
>>
>> This sounds worth trying. We'll need to test it on a wide range of
>> devices though, both internal and external.

Ack, as mentioned in the other mail which I just send I think
this is worth trying.

> We still need a plan for asynchronous controls.

As I mentioned in that other email I think we can do the same there.

So basically delay powering up the camera from /dev/video# open till
the first moment we actually need to communicate to the camera and
track per file-handle if we did a usb_autopm_get_interface() for
that file-handle and if yes, then do the put-interface on file-handle
close.

> And we have to decide if we stop supporting the uvc button (maybe we
> can start by moving USB_VIDEO_CLASS_INPUT_EVDEV to staging and see
> what happens?)

As I mentioned in other threads I do not think that the button
only working changing from:

"only works when /dev/video# is open"

to:

"only works when streaming from /dev/video#"

(or actually only works when some action on the camera which
requires it to be powered-on has been done).

is a big deal, since most apps which open /dev/video# for
a longer time will almost always do so to actually do something
with the camera, at which point the button will work just as
before.

And for apps which only do a short-lived open of /dev/video#
the button does not work with the current code either.

TL;DR: IMHO it is fine if the button only works when streaming.

Regards,

Hans