Some camera modules have XU controls that can configure the behaviour of
the privacy LED.

Block mapping of those controls, unless the module is configured with
a new parameter: allow_privacy_override.

Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
 drivers/media/usb/uvc/uvc_driver.c |  5 +++++
 drivers/media/usb/uvc/uvc_v4l2.c   | 32 ++++++++++++++++++++++++++++++++
 drivers/media/usb/uvc/uvcvideo.h   |  1 +
 include/linux/usb/uvc.h            |  4 ++++
 4 files changed, 42 insertions(+)

diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 71563d8f4bcf581694ccd4b665ff52b629caa0b6..d50c501121e6f774dfd6cfdb859279e0860d06a5 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -35,6 +35,7 @@ unsigned int uvc_hw_timestamps_param;
 static unsigned int uvc_quirks_param = -1;
 unsigned int uvc_dbg_param;
 unsigned int uvc_timeout_param = UVC_CTRL_STREAMING_TIMEOUT;
+bool uvc_allow_privacy_override_param;
 
 static struct usb_driver uvc_driver;
 
@@ -2473,6 +2474,10 @@ module_param_named(trace, uvc_dbg_param, uint, 0644);
 MODULE_PARM_DESC(trace, "Trace level bitmask");
 module_param_named(timeout, uvc_timeout_param, uint, 0644);
 MODULE_PARM_DESC(timeout, "Streaming control requests timeout");
+module_param_named(allow_privacy_override, uvc_allow_privacy_override_param,
+		   bool, 0644);
+MODULE_PARM_DESC(allow_privacy_override,
+		 "Allow UVCIOC_CTRL_MAP ioctl map privacy related control");
 
 /* ------------------------------------------------------------------------
  * Driver initialization and cleanup
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 03c64b5698bf4331fed8437fa6e9c726a07450bd..e067b8f38500299fe6acc7e3b9770f7374748823 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -18,6 +18,7 @@
 #include <linux/mm.h>
 #include <linux/wait.h>
 #include <linux/atomic.h>
+#include <linux/usb/uvc.h>
 
 #include <media/v4l2-common.h>
 #include <media/v4l2-ctrls.h>
@@ -121,6 +122,32 @@ static int uvc_control_add_xu_mapping(struct uvc_video_chain *chain,
 /* ------------------------------------------------------------------------
  * UVC ioctls
  */
+
+static bool uvc_is_privacy_mapping(struct uvc_xu_control_mapping *xmap)
+{
+	struct mapping {
+		u8 entity[16];
+		u8 selector;
+	} privacy_mappings[] = {
+		{
+			.entity = UVC_GUID_LOGITECH_USER_HW_CONTROL_V1,
+			.selector = 1,
+		},
+		{
+			.entity = UVC_GUID_LOGITECH_PERIPHERAL,
+			.selector = 9,
+		},
+	};
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(privacy_mappings); i++)
+		if (!memcmp(xmap->entity, privacy_mappings[i].entity, 16) &&
+		    xmap->selector == privacy_mappings[i].selector)
+			return true;
+
+	return false;
+}
+
 static int uvc_ioctl_xu_ctrl_map(struct uvc_video_chain *chain,
 				 struct uvc_xu_control_mapping *xmap)
 {
@@ -133,6 +160,11 @@ static int uvc_ioctl_xu_ctrl_map(struct uvc_video_chain *chain,
 		return -EINVAL;
 	}
 
+	if (uvc_is_privacy_mapping(xmap) && !uvc_allow_privacy_override_param) {
+		pr_warn_once("uvcvideo: Privacy related controls can only be mapped if param allow_privacy_override is true\n");
+		return -EINVAL;
+	}
+
 	map = kzalloc(sizeof(*map), GFP_KERNEL);
 	if (map == NULL)
 		return -ENOMEM;
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 9a86d7f1f6ea022dace87614030bf0fde0d260f0..1895e4fe45e9c0246b7f0613dd2bc51f60b78759 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -662,6 +662,7 @@ extern unsigned int uvc_clock_param;
 extern unsigned int uvc_dbg_param;
 extern unsigned int uvc_timeout_param;
 extern unsigned int uvc_hw_timestamps_param;
+extern bool uvc_allow_privacy_override_param;
 
 #define uvc_dbg(_dev, flag, fmt, ...)					\
 do {									\
diff --git a/include/linux/usb/uvc.h b/include/linux/usb/uvc.h
index b939a01da11466747249c64c72a3ea40cd364a59..f2d6cf52427ce9c0a62a80ca3629c6e350fa02c8 100644
--- a/include/linux/usb/uvc.h
+++ b/include/linux/usb/uvc.h
@@ -41,6 +41,10 @@
 #define UVC_GUID_LOGITECH_PERIPHERAL \
 	{0x21, 0x2d, 0xe5, 0xff, 0x30, 0x80, 0x2c, 0x4e, \
 	 0x82, 0xd9, 0xf5, 0x87, 0xd0, 0x05, 0x40, 0xbd }
+#define UVC_GUID_LOGITECH_USER_HW_CONTROL_V1 \
+	{0x82, 0x06, 0x61, 0x63, 0x70, 0x50, 0xab, 0x49, \
+	 0xb8, 0xcc, 0xb3, 0x85, 0x5e, 0x8d, 0x22, 0x1f }
+
 
 /* https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5#222-extension-unit-controls */
 #define UVC_MSXU_CONTROL_FOCUS			0x01

-- 
2.52.0.rc1.455.g30608eb744-goog

On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> Some camera modules have XU controls that can configure the behaviour of
> the privacy LED.
> 
> Block mapping of those controls, unless the module is configured with
> a new parameter: allow_privacy_override.

This is not the 1990's, please do not add new module parameters, they do
not scale, nor work properly at all for modern hardware where you can
have multiple devices in the same system.

This isn't an agreement that we should do this feature at all, just that
if you do, it should NOT be a module parameter.

thanks,

greg k-h

On Tue, Nov 18, 2025 at 06:14:09AM -0500, Greg Kroah-Hartman wrote:
> On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> > Some camera modules have XU controls that can configure the behaviour of
> > the privacy LED.
> > 
> > Block mapping of those controls, unless the module is configured with
> > a new parameter: allow_privacy_override.
> 
> This is not the 1990's, please do not add new module parameters, they do
> not scale, nor work properly at all for modern hardware where you can
> have multiple devices in the same system.
> 
> This isn't an agreement that we should do this feature at all, just that
> if you do, it should NOT be a module parameter.

I agree with Greg: modprobe makes things harder specially on usb.

Also, in the specific case of privacy leds, IMO it should never be
possible to directly disable it, not even root via a modprobe or
runtime parameter.

Ok, as it might be some case where someone really wants to disable for his
special pet toy. If such cases are relevant, a Kconfig parameter could
be added (maybe depending on BROKEN), having privacy LED enabled by default. 

This way, any sane distro-generated Kernel should always have the privacy
LED on when camera is in use. 

On other words, if someone has secure boot enabled, he can be more confident
that a distro-vendor signed Kernel will honour the privacy LED, and not
even the root can tamper with - as BIOS access to disable secure boot would
be needed to change it - plus, booting a non-signed kernel.

Regards,
Mauro

On Tue, Nov 18, 2025 at 03:09:16PM +0100, Mauro Carvalho Chehab wrote:
> On Tue, Nov 18, 2025 at 06:14:09AM -0500, Greg Kroah-Hartman wrote:
> > On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> > > Some camera modules have XU controls that can configure the behaviour of
> > > the privacy LED.
> > > 
> > > Block mapping of those controls, unless the module is configured with
> > > a new parameter: allow_privacy_override.
> > 
> > This is not the 1990's, please do not add new module parameters, they do
> > not scale, nor work properly at all for modern hardware where you can
> > have multiple devices in the same system.
> > 
> > This isn't an agreement that we should do this feature at all, just that
> > if you do, it should NOT be a module parameter.
> 
> I agree with Greg: modprobe makes things harder specially on usb.
> 
> Also, in the specific case of privacy leds, IMO it should never be
> possible to directly disable it, not even root via a modprobe or
> runtime parameter.
> 
> Ok, as it might be some case where someone really wants to disable for his
> special pet toy. If such cases are relevant, a Kconfig parameter could
> be added (maybe depending on BROKEN), having privacy LED enabled by default. 

The feature was added by Logitech to their webcams to avoid the red
privacy LED showing as a reflection on users' glasses. Whether or not
users ended up caring, I don't know.

The situation is different for webcams embedded in devices (even if
they're internally UVC cameras), as the privacy LED is typically smaller
and less bright in those devices.

> This way, any sane distro-generated Kernel should always have the privacy
> LED on when camera is in use. 
> 
> On other words, if someone has secure boot enabled, he can be more confident
> that a distro-vendor signed Kernel will honour the privacy LED, and not
> even the root can tamper with - as BIOS access to disable secure boot would
> be needed to change it - plus, booting a non-signed kernel.

-- 
Regards,

Laurent Pinchart

Hi Mauro

On Tue, 18 Nov 2025 at 15:09, Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> On Tue, Nov 18, 2025 at 06:14:09AM -0500, Greg Kroah-Hartman wrote:
> > On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> > > Some camera modules have XU controls that can configure the behaviour of
> > > the privacy LED.
> > >
> > > Block mapping of those controls, unless the module is configured with
> > > a new parameter: allow_privacy_override.
> >
> > This is not the 1990's, please do not add new module parameters, they do
> > not scale, nor work properly at all for modern hardware where you can
> > have multiple devices in the same system.
> >
> > This isn't an agreement that we should do this feature at all, just that
> > if you do, it should NOT be a module parameter.
>
> I agree with Greg: modprobe makes things harder, especially on usb.

If the argument is that with parameters you cannot have a different
parameter for each USB camera, I would say that I see this option as a
system-wide policy, not as a per-device option. But yeah, the less
parameters that we have, the better.

>
> Also, in the specific case of privacy leds, IMO it should never be
> possible to directly disable it, not even root via a modprobe or
> runtime parameter.

+1

>
> Ok, as it might be some case where someone really wants to disable for his
> special pet toy. If such cases are relevant, a Kconfig parameter could
> be added (maybe depending on BROKEN), having privacy LED enabled by default.
>
> This way, any sane distro-generated Kernel should always have the privacy
> LED on when camera is in use.
>
> On other words, if someone has secure boot enabled, he can be more confident
> that a distro-vendor signed Kernel will honour the privacy LED, and not
> even the root can tamper with - as BIOS access to disable secure boot would
> be needed to change it - plus, booting a non-signed kernel.

If most of the people agree that the final goal is to block all the
LED privacy access from userspace we could have a mixed approach.

1. We introduce the allow_privacy_override parameter with default off.
If the user sets allow_privacy_override, they are welcomed with a message like:

uvcvideo: [DEPRECATION]: Access to the privacy controls will be
eventually blocked.

2. In one year, if nobody screams at us we remove the parameter and
call it a day.

3. If someone depends on this feature, we will move it into a kernel
configuration behind BROKEN.

What do you think?

>
> Regards,
> Mauro



-- 
Ricardo Ribalda

On Tue, 18 Nov 2025 15:09:16 +0100, Mauro Carvalho Chehab wrote:
> On other words, if someone has secure boot enabled, he can be more
> confident that a distro-vendor signed Kernel will honour the privacy
> LED, and not even the root can tamper with - as BIOS access to
> disable secure boot would be needed to change it - plus, booting a
> non-signed kernel.

IMHO users are better off trusting duct tape than any chain of trust,
and those with tinfoil hats already do.

Rational people with any clue will simply assume their computer broke
and put duct tape over the LED, carefully not to cover the lens ;)

Regards,
Michal

Hi Ricardo,

On Mon, 2025-11-17 at 20:14 +0000, Ricardo Ribalda wrote:
> +	if (uvc_is_privacy_mapping(xmap) && !uvc_allow_privacy_override_param) {
> +		pr_warn_once("uvcvideo: Privacy related controls can only be mapped if param allow_privacy_override is true\n");
> +		return -EINVAL;
> +	}
> +

To really prevent the LED from being turned off, it should also be
added to uvc_xu_ctrl_query.

But why has it become so important after 10+ years that it cannot be
turned off on Linux? What has changed?
The majority of users use open-source software, they can view the
source at any time.


Gergo

On Mon, 17 Nov 2025 at 22:10, Gergo Koteles <soyer@irl.hu> wrote:
>
> Hi Ricardo,

Hi Gergo

>
> On Mon, 2025-11-17 at 20:14 +0000, Ricardo Ribalda wrote:
> > +     if (uvc_is_privacy_mapping(xmap) && !uvc_allow_privacy_override_param) {
> > +             pr_warn_once("uvcvideo: Privacy related controls can only be mapped if param allow_privacy_override is true\n");
> > +             return -EINVAL;
> > +     }
> > +
>
> To really prevent the LED from being turned off, it should also be
> added to uvc_xu_ctrl_query.

Will add in in v2. Thanks.

I wanted to get the ball rolling first :)

>
> But why has it become so important after 10+ years that it cannot be
> turned off on Linux? What has changed?
> The majority of users use open-source software, they can view the
> source at any time.

Most users expect that the led is always on when the camera is active.
I think the usecases where the led should not be turned on are spooky
or very limited.

Even if you use open-source software, when it parses user generated
data, there is a risk for bugs. If there is a bug the only thing
protecting the security of the camera is the membership of the video
group which is a very low barrier. And once you manage to change the
LED behaviour will persist in other unrelated apps.

With the current proposal you need to actively enable the
privacy_override_param, which typically requires root access.

Regards!


>
>
> Gergo



-- 
Ricardo Ribalda

Hi Ricardo,

On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> 
> Most users expect that the led is always on when the camera is active.
> I think the usecases where the led should not be turned on are spooky
> or very limited.
> 

Or do most users expect that if a piece of hardware has a setting, they
can set it without module parameters?

> Even if you use open-source software, when it parses user generated
> data, there is a risk for bugs. If there is a bug the only thing
> protecting the security of the camera is the membership of the video
> group which is a very low barrier. And once you manage to change the
> LED behaviour will persist in other unrelated apps.
> 

So this is about what if an attacker accessed my passwords, private
keys, OTP tokens, emails, pictures and then couldn't take a fresh
picture of me in the dark without an LED? I'm smart as hell and I use a
privacy tape anyway ;)

I think freedom is worth more than this kind of fear.


Gergo

Hi Gergo

On Tue, 18 Nov 2025 at 09:48, Gergo Koteles <soyer@irl.hu> wrote:
>
> Hi Ricardo,
>
> On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> >
> > Most users expect that the led is always on when the camera is active.
> > I think the usecases where the led should not be turned on are spooky
> > or very limited.
> >
>
> Or do most users expect that if a piece of hardware has a setting, they
> can set it without module parameters?

A piece of hardware that has a non-standard, undocumented setting.

Do you have a compelling use-case for turning off the privacy LED?

>
> > Even if you use open-source software, when it parses user generated
> > data, there is a risk for bugs. If there is a bug the only thing
> > protecting the security of the camera is the membership of the video
> > group which is a very low barrier. And once you manage to change the
> > LED behaviour will persist in other unrelated apps.
> >
>
> So this is about what if an attacker accessed my passwords, private
> keys, OTP tokens, emails, pictures and then couldn't take a fresh
> picture of me in the dark without an LED? I'm smart as hell and I use a
> privacy tape anyway ;)

My core goal is simple: if the camera is in use, the privacy LED must
be ON. If the LED is ON unexpectedly, it serves as a clear indication
that something unusual is happening.

Gaining access to the video node does not automatically grant access
to sensitive data like browser information; there are sandboxes in
place for that. Also open source does not equate to secure or
non-malicious code.

>
> I think freedom is worth more than this kind of fear.

No freedom is lost. This change simply increases the
trustworthiness/reliability of your device.

On ChromeOS, I don't use a privacy tape, but that's because I know how
the LED is wired :). I want to achieve a similar level of
trust/reliability for everyone else.

In other words, I want to know if someone has seen me without t-shirt,
eating ice-cream and crying while I am re-watching Coco.

>
>
> Gergo



-- 
Ricardo Ribalda

On Tue, Nov 18, 2025 at 10:25:42AM +0100, Ricardo Ribalda wrote:
> On Tue, 18 Nov 2025 at 09:48, Gergo Koteles wrote:
> > On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> > >
> > > Most users expect that the led is always on when the camera is active.
> > > I think the usecases where the led should not be turned on are spooky
> > > or very limited.
> >
> > Or do most users expect that if a piece of hardware has a setting, they
> > can set it without module parameters?
> 
> A piece of hardware that has a non-standard, undocumented setting.
> 
> Do you have a compelling use-case for turning off the privacy LED?

The use case that Logitech added this XU control to support is avoiding
the reflection of the privacy LED in users' glasses.

> > > Even if you use open-source software, when it parses user generated
> > > data, there is a risk for bugs. If there is a bug the only thing
> > > protecting the security of the camera is the membership of the video
> > > group which is a very low barrier.

In modern systems the answer to this would be pipewire and portals (or
similar solutions for vendor operating systems). We'll still need time
until the user won't have direct access to the video device nodes
though.

> > > And once you manage to change the
> > > LED behaviour will persist in other unrelated apps.

Maybe that's something we want to address, and make the control
per-file-handle ?

> > So this is about what if an attacker accessed my passwords, private
> > keys, OTP tokens, emails, pictures and then couldn't take a fresh
> > picture of me in the dark without an LED? I'm smart as hell and I use a
> > privacy tape anyway ;)
> 
> My core goal is simple: if the camera is in use, the privacy LED must
> be ON. If the LED is ON unexpectedly, it serves as a clear indication
> that something unusual is happening.
> 
> Gaining access to the video node does not automatically grant access
> to sensitive data like browser information; there are sandboxes in
> place for that. Also open source does not equate to secure or
> non-malicious code.
> 
> > I think freedom is worth more than this kind of fear.
> 
> No freedom is lost. This change simply increases the
> trustworthiness/reliability of your device.
> 
> On ChromeOS, I don't use a privacy tape, but that's because I know how
> the LED is wired :). I want to achieve a similar level of
> trust/reliability for everyone else.

I'd argue that a privacy tape is useful on those devices too. Far more
common than attack scenarios are cases when you unvoluntarily turn your
webcam on during a call. This is however beside the point.

> In other words, I want to know if someone has seen me without t-shirt,
> eating ice-cream and crying while I am re-watching Coco.

-- 
Regards,

Laurent Pinchart

Hi Ricardo,

On Tue, 2025-11-18 at 10:25 +0100, Ricardo Ribalda wrote:
> Hi Gergo
> 
> On Tue, 18 Nov 2025 at 09:48, Gergo Koteles <soyer@irl.hu> wrote:
> > 
> > Hi Ricardo,
> > 
> > On Tue, 2025-11-18 at 07:21 +0100, Ricardo Ribalda wrote:
> > > 
> > > Most users expect that the led is always on when the camera is active.
> > > I think the usecases where the led should not be turned on are spooky
> > > or very limited.
> > > 
> > 
> > Or do most users expect that if a piece of hardware has a setting, they
> > can set it without module parameters?
> 
> A piece of hardware that has a non-standard, undocumented setting.
> 
> Do you have a compelling use-case for turning off the privacy LED?
> 

As a pet camera, it is useful to be able to turn off the LED.
In some cases, it can also eliminate unwanted reflections.
Some cameras may have blue LED, and if someone hates blue LEDs..

> > 
> > > Even if you use open-source software, when it parses user generated
> > > data, there is a risk for bugs. If there is a bug the only thing
> > > protecting the security of the camera is the membership of the video
> > > group which is a very low barrier. And once you manage to change the
> > > LED behaviour will persist in other unrelated apps.
> > > 
> > 
> > So this is about what if an attacker accessed my passwords, private
> > keys, OTP tokens, emails, pictures and then couldn't take a fresh
> > picture of me in the dark without an LED? I'm smart as hell and I use a
> > privacy tape anyway ;)
> 
> My core goal is simple: if the camera is in use, the privacy LED must
> be ON. If the LED is ON unexpectedly, it serves as a clear indication
> that something unusual is happening.
> 
> Gaining access to the video node does not automatically grant access
> to sensitive data like browser information; there are sandboxes in
> place for that. Also open source does not equate to secure or
> non-malicious code.
> 

Applications that access a video node usually have multiple permissions
(at least on my system). But I understand there may be cases where they
only have access to a video node and then this can be useful.

> > 
> > I think freedom is worth more than this kind of fear.
> 
> No freedom is lost. This change simply increases the
> trustworthiness/reliability of your device.

It will decrease to the extent that fewer people will know that such an
option exists because they will not read the description of the
module's parameters.

And people won't even know that it can be turned off as root, and even
a curl | sudo... installation can take a picture of them without an
LED.

And it's not possible to be sure that there isn't another undocumented
option in the firmware to turn it off the LED.

A physical switch would be the best for this control, but that's not an
option :(



Gergo

Hi George,

On 18-Nov-25 12:14 PM, Gergo Koteles wrote:

..

>> Do you have a compelling use-case for turning off the privacy LED?
>>
> 
> As a pet camera, it is useful to be able to turn off the LED.
> In some cases, it can also eliminate unwanted reflections.
> Some cameras may have blue LED, and if someone hates blue LEDs..

And almost all cameras already do not allow manually overriding the LED
turning on while streaming. There is a very low-tech solution for this,
put some black isolation tape over the LED :)

>> My core goal is simple: if the camera is in use, the privacy LED must
>> be ON. If the LED is ON unexpectedly, it serves as a clear indication
>> that something unusual is happening.

...

>> No freedom is lost. This change simply increases the
>> trustworthiness/reliability of your device.
> 
> It will decrease to the extent that fewer people will know that such an
> option exists because they will not read the description of the
> module's parameters.

People currently already will not know that the option exists.

Seeing the current LED controls on Logitech cams requires 2 manual steps:

1. Install uvcdynctrl which maps the custom GUIDs to the LED controls
   Note distros do not install this be default
2. Use either a GUI v4l2-control app like qv4l2ucp or gtk-v4l, or
   v4l-ctrl -l to list controls and then change the setting.

So there already is close to 0 discoverability for this Logitech
only feature.

For the new MIPI cameras on laptops we have deliberately made it
impossible to disable the privacy LED while streaming even though
it is often controlled by a separate GPIO because of privacy reasons.

For the same privacy reasons I fully agree with Ricardo that this should
be behind a module option. Which replaces step 1. with creating
a /etc/modprobe.d/uvc.conf file, so just about as much work.

> And it's not possible to be sure that there isn't another undocumented
> option in the firmware to turn it off the LED.
> 
> A physical switch would be the best for this control, but that's not an
> option :(

Sure but remember perfect is the enemy of good. Having a v4l2-ctrl to
force the LED to always be off will make it a lot easier for an attacker
to use the camera without the LED turning on. Security is all about
layers / defense in depth and the module option is a nice and simple
way to make things harder for pervert spyware.

Regards,

Hans

Hi Hans,

On Tue, 2025-11-18 at 15:26 +0100, Hans de Goede wrote:

> 
> > > Do you have a compelling use-case for turning off the privacy LED?
> > > 
> > 
> > As a pet camera, it is useful to be able to turn off the LED.
> > In some cases, it can also eliminate unwanted reflections.
> > Some cameras may have blue LED, and if someone hates blue LEDs..
> 
> And almost all cameras already do not allow manually overriding the LED
> turning on while streaming. There is a very low-tech solution for this,
> put some black isolation tape over the LED :)
> 

Yes, this is also a good and stable solution. :)

> > > My core goal is simple: if the camera is in use, the privacy LED must
> > > be ON. If the LED is ON unexpectedly, it serves as a clear indication
> > > that something unusual is happening.
> 
> ...
> 
> > > No freedom is lost. This change simply increases the
> > > trustworthiness/reliability of your device.
> > 
> > It will decrease to the extent that fewer people will know that such an
> > option exists because they will not read the description of the
> > module's parameters.
> 
> People currently already will not know that the option exists.
> 
> Seeing the current LED controls on Logitech cams requires 2 manual steps:
> 
> 1. Install uvcdynctrl which maps the custom GUIDs to the LED controls
>    Note distros do not install this be default
> 2. Use either a GUI v4l2-control app like qv4l2ucp or gtk-v4l, or
>    v4l-ctrl -l to list controls and then change the setting.
> 
> So there already is close to 0 discoverability for this Logitech
> only feature.

This is not completely true.
The cameractrls uses these extensions and controls with
uvc_xu_control_query() and has over 140k downloads on Flathub alone.

> 
> For the new MIPI cameras on laptops we have deliberately made it
> impossible to disable the privacy LED while streaming even though
> it is often controlled by a separate GPIO because of privacy reasons.
> 
> For the same privacy reasons I fully agree with Ricardo that this should
> be behind a module option. Which replaces step 1. with creating
> a /etc/modprobe.d/uvc.conf file, so just about as much work.
> 

I agree that this will be useful. The module parameter is also simpler
than per-V4L2 control permission management. And the latter is not
needed in other cases, I think.

However, if allow_privacy_override is enabled, would it be worth
mapping these controls by the kernel?
So uvcdynctrl or cameractrls would not be needed for this control.
> 

Regards,
Gergo

Hi Gergo

On Tue, 18 Nov 2025 at 16:36, Gergo Koteles <soyer@irl.hu> wrote:
>
> Hi Hans,
>
> On Tue, 2025-11-18 at 15:26 +0100, Hans de Goede wrote:
>
> >
> > > > Do you have a compelling use-case for turning off the privacy LED?
> > > >
> > >
> > > As a pet camera, it is useful to be able to turn off the LED.
> > > In some cases, it can also eliminate unwanted reflections.
> > > Some cameras may have blue LED, and if someone hates blue LEDs..
> >
> > And almost all cameras already do not allow manually overriding the LED
> > turning on while streaming. There is a very low-tech solution for this,
> > put some black isolation tape over the LED :)
> >
>
> Yes, this is also a good and stable solution. :)
>
> > > > My core goal is simple: if the camera is in use, the privacy LED must
> > > > be ON. If the LED is ON unexpectedly, it serves as a clear indication
> > > > that something unusual is happening.
> >
> > ...
> >
> > > > No freedom is lost. This change simply increases the
> > > > trustworthiness/reliability of your device.
> > >
> > > It will decrease to the extent that fewer people will know that such an
> > > option exists because they will not read the description of the
> > > module's parameters.
> >
> > People currently already will not know that the option exists.
> >
> > Seeing the current LED controls on Logitech cams requires 2 manual steps:
> >
> > 1. Install uvcdynctrl which maps the custom GUIDs to the LED controls
> >    Note distros do not install this be default
> > 2. Use either a GUI v4l2-control app like qv4l2ucp or gtk-v4l, or
> >    v4l-ctrl -l to list controls and then change the setting.
> >
> > So there already is close to 0 discoverability for this Logitech
> > only feature.
>
> This is not completely true.
> The cameractrls uses these extensions and controls with
> uvc_xu_control_query() and has over 140k downloads on Flathub alone.
>
> >
> > For the new MIPI cameras on laptops we have deliberately made it
> > impossible to disable the privacy LED while streaming even though
> > it is often controlled by a separate GPIO because of privacy reasons.
> >
> > For the same privacy reasons I fully agree with Ricardo that this should
> > be behind a module option. Which replaces step 1. with creating
> > a /etc/modprobe.d/uvc.conf file, so just about as much work.
> >
>
> I agree that this will be useful. The module parameter is also simpler
> than per-V4L2 control permission management. And the latter is not
> needed in other cases, I think.
>
> However, if allow_privacy_override is enabled, would it be worth
> mapping these controls by the kernel?
> So uvcdynctrl or cameractrls would not be needed for this control.

If allow_privacy_override is enabled and there is a standard control
in include/uapi/linux/v4l2-controls.h that supports such control: I
have no issue adding the mapping for it.

Right now we only have V4L2_CID_PRIVACY which is a boolean and has
usually been used to tell if the privacy shutter is on or off, not to
configure the LED.

In any case, the default value of allow_privacy_override should be
false. I would even argue that the best approach is to block all the
known LED config controls after a deprecation period.
Check: https://lore.kernel.org/linux-media/CANiDSCuv8UG6TMx6pK348okK+NYzAorPEgPYzoRCEZiBDgPP=A@mail.gmail.com/

> >
>
> Regards,
> Gergo



-- 
Ricardo Ribalda

Hi Ricardo,

On Tue, 2025-11-18 at 19:30 +0100, Ricardo Ribalda wrote:


...

> > 
> > > 
> > > For the new MIPI cameras on laptops we have deliberately made it
> > > impossible to disable the privacy LED while streaming even though
> > > it is often controlled by a separate GPIO because of privacy reasons.
> > > 
> > > For the same privacy reasons I fully agree with Ricardo that this should
> > > be behind a module option. Which replaces step 1. with creating
> > > a /etc/modprobe.d/uvc.conf file, so just about as much work.
> > > 
> > 
> > I agree that this will be useful. The module parameter is also simpler
> > than per-V4L2 control permission management. And the latter is not
> > needed in other cases, I think.
> > 
> > However, if allow_privacy_override is enabled, would it be worth
> > mapping these controls by the kernel?
> > So uvcdynctrl or cameractrls would not be needed for this control.
> 
> If allow_privacy_override is enabled and there is a standard control
> in include/uapi/linux/v4l2-controls.h that supports such control: I
> have no issue adding the mapping for it.
> 

I was misled by V4L2_CID_LED1_MODE in uvcdynctrl's logitech.xml.
That is not in v4l-controls.h.

> Right now we only have V4L2_CID_PRIVACY which is a boolean and has
> usually been used to tell if the privacy shutter is on or off, not to
> configure the LED.
> 
> In any case, the default value of allow_privacy_override should be
> false. I would even argue that the best approach is to block all the
> known LED config controls after a deprecation period.
> Check: https://lore.kernel.org/linux-media/CANiDSCuv8UG6TMx6pK348okK+NYzAorPEgPYzoRCEZiBDgPP=A@mail.gmail.com/
> 

I use these controls now and would use them in 1-2-3 years, so I don't
think removing them completely is a good idea :)

Almost no one compiles their own kernel anymore, so the usefulness of
putting them behind a kernel configuration is questionable.

I also saw these being used in the users of motion project. If someone
is using it as a surveillance camera, there is no need for it to light
up.

The c920 has LEDs like this, that are not easy to cover up with tape
and definitely not aesthetic.
https://www.nikktech.com/main/images/pics/reviews/logitech/c920_webcam/logitech_c920_015.JPG


Regards,
Gergo