From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 827E73EC2C5 for ; Tue, 24 Mar 2026 12:07:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774354047; cv=none; b=Ih+5rKOqChwGDKEJpU78u1MWEqmy6mmvOci7/6PYQH7KCcdxuhYARQd5G2jEiVS3Pj3GLsqKFRb4t5sAvTtkqEqvCsyRirqqRblKsMg5fLRmygU14aBba2NzxjVc6zstC9OVTEHpkwPYK52q1u8Ai14dR9kfvZGx4HuKBUE3oJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774354047; c=relaxed/simple; bh=2G2a51QCI8K6f2AwRf56MeFUJ5650ustP3qdsf8Veo8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FEaPk39c6Zz4RzHOft9qmwPWF/IDqfWi5TRnXBHWIyQwAFlraVTEJBEDRgHruPcpokCAyIpSfq1V29kNHeWLKzr7yzqpvImkzOJTksdwPE2rtn7YNW3rxsNpvbhbgJw3lCNriN87H9X1hMNAm6gmbLpMRSyxctgg9RJd1ixR6Ro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZR90S3Rz; arc=none smtp.client-ip=209.85.218.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZR90S3Rz" Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-b979d16dd0cso773610466b.1 for ; Tue, 24 Mar 2026 05:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774354039; x=1774958839; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=1wv+DLyB0PVqSatPGWYmQ5Ga0Kax66FYWMD7mQDfKzI=; b=ZR90S3RzL0FuGJmBbP13CsLxglC+mh+PAWa0BlVIv39dZ2ZNo3jqwXgoDYCPtV9vJy k2UEKn82B0qgYDOursZFN15cZbQvjJzT8TtcOQPBTrFI7+vR8k8Cdg/CDcb67avvPvjI KQ6IEKc5xokmhKlJGKXGKLZWM6Tq9vOaOQvjMdRf9InizGaR8k6ID0uXyqchw+aulotG pML5Wx5TgB9UuCLYtM01z5DCq8xxkNjvtaD8JfbfjkkOnaNxOGz/SWnSjqEDtMt9dMMN MqF9K21/H5KgyVjauxA2aZPCgHbU09RKASKPb6tBCeD8BivBVV2QN5zvAVDwcl6p78lA Xz/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774354039; x=1774958839; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1wv+DLyB0PVqSatPGWYmQ5Ga0Kax66FYWMD7mQDfKzI=; b=ZNGOVQtqKavx1fYSVwymXfEMdpY4D+x/hkmiHgr9glNQvH2zgkivDDojGyOlwfMPVb 1AjgbbLrY/EIIrvmYNfK1ZMLZ2+eH/UruRpnhb+LFVwAd7K7Q8PlubXRcrgfT0PKIfJM A621mOBxqGcJDpmqtap4twFhvBI6/8xus2QmxMqCJ16RDo3y35eMBll6PwGdwEyFvfJU 8wR/B/keRxcApKHT2ibDQ18wjg2ucVneRcAVzgefNNo1ndF6RDVT48RVCSgmbvvIvL+M 0pIlzgIy8iVVtE6s3qN8Y0H8HS2bZl7/urtAgmCaKfz1UfNUfX3naPRFmAfM6xop8umg M7tQ== X-Forwarded-Encrypted: i=1; AJvYcCVXrOhiy3cy4xurPsmYw9GB/g9Ot1ndFXL+59jSsJ6qrD5/tcAMGemgnA+cPAMO0Cvi/4pC/ldrSIEGhpQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyQTBRHZPbjPBBAF589fL0fuEgC6zQXoo5NoAT2dafID/tZaMZh 8degKoiGIVuRhZ7HUzQih94P9qTEWzdGIT5+xUCI57E+JiwIsIITZsdl X-Gm-Gg: ATEYQzxrRYqzqw16MnLJqeT8+35nO9wuTCDW9LT/2IjvtIhXW+rUhKFPQKEFW2sKcMw bn2jVXvzMLQmZ2PB+lMkYvlwHXDM19AInplGqvgnPN5LF07dN2RLQa1giMLpOzfj4s4v08Vm/mp yFGT+Sd9RiPtWXHH5JGK2HYgPX6ksQ4f/8Ftl+6Ii5XUcr4uRx/SuNZqcnElgtMBUlHVOVRSFca TRole2YFpmQF5/qJMhJ7xC9j9ut0lDBKuYGf4rlYd4yrijIp377l5fQZs3jBPYs/cf28stnrs9q sj4ihOpdP+k1M9pyVVQyTyEFawc4/lHCasea1fe6esX7OD5MokQ7Gen7RdA1+Pm/dHjJIalJF4j 2Hjc3eDy1ngOwG6I87wgxLnEUPN0fjpY3CVwOuC7KcCoHXnFyiD3RzL3XIfEETWmoRxsMUfBvx7 hw5bCIVLO8BUPveZI14Fmdpw+DbDPWp9Tl5U0= X-Received: by 2002:a17:906:6da:b0:b8f:a174:3186 with SMTP id a640c23a62f3a-b982f3e783dmr947383166b.57.1774354038059; Tue, 24 Mar 2026 05:07:18 -0700 (PDT) Received: from foxbook (bfk214.neoplus.adsl.tpnet.pl. [83.28.48.214]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b98335de16csm643772766b.41.2026.03.24.05.07.16 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 24 Mar 2026 05:07:17 -0700 (PDT) Date: Tue, 24 Mar 2026 13:07:13 +0100 From: Michal Pecio To: Ricardo Ribalda Cc: Laurent Pinchart , Hans de Goede , Mauro Carvalho Chehab , Greg Kroah-Hartman , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v3 3/4] media: uvcvideo: Introduce allow_privacy_override module parameter Message-ID: <20260324130713.5c9c3633.michal.pecio@gmail.com> In-Reply-To: References: <20260316-uvcdynctrl-v3-0-19cd4657e1f3@chromium.org> <20260316-uvcdynctrl-v3-3-19cd4657e1f3@chromium.org> <20260319013657.155efeb0.michal.pecio@gmail.com> <20260319120856.09f2f15a.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 19 Mar 2026 12:43:21 +0100, Ricardo Ribalda wrote: > > > We can then decide if we need a specialized API for their use > > > case or a Kconfig option, rather than leaving the current "anyone > > > can turn off the privacy LED" status quo. > > > > Why not just add the specialized API right away? > > We don't know the exact use cases yet, and I do not want to design > an API without understanding the users for it. > > At this moment, we have only identified these usecases: > > - Disabling the LED to avoid reflections in glasses. (This is > generally a non-issue with modern hardware). > - Baby monitors. (I would argue that physical tape is the correct > solution for a sleep-disturbing light). Indeed it was a rhetorical question, I suspect this won't go anywhere beyond the module parameter for lack of interest from users. Apparently it's a niche thing and it already works well enough for those who care. Kconfig could make more sense to exclude this whole "filtering" logic for those who don't care and may not appreciate bloat, e.g. embedded. > I rely on my LEDs. I know they are wired to the sensor power supply, > so the LED is definitely on when the camera is in use. > I want all users to be able to trust their LEDs like I do. This is objectively impossible without a soldering iron, and trust in something that's not even real is ralely a good thing. Ultimately it's just a software controllable LED. Anyone can drive it through USBFS. You have a point that restricting this in uvcvideo may keep some sandboxed applications on some HW from behaving in a manner unexpected by some users, but that's about the limit of it. And I wish that you enjoyed the same flexibility as those Logitech camera owners. But you wouldn't want me to try make it happen ;) Regards, Michal