Hi,
On 26-Nov-24 6:12 PM, Ricardo Ribalda wrote:
On Tue, 26 Nov 2024 at 17:51, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
On Tue, Nov 26, 2024 at 05:27:57PM +0100, Ricardo Ribalda wrote:
On Mon, 25 Nov 2024 at 22:35, Laurent Pinchart wrote:
On Mon, Nov 25, 2024 at 03:41:19PM +0100, Hans de Goede wrote:
On 25-Nov-24 2:14 PM, Laurent Pinchart wrote:
On Mon, Nov 25, 2024 at 01:01:14PM +0100, Hans de Goede wrote: > On 18-Nov-24 5:47 PM, Ricardo Ribalda wrote: >> On Mon, 18 Nov 2024 at 16:43, Hans de Goede wrote: >>> On 15-Nov-24 9:20 AM, Ricardo Ribalda wrote: >>>> On Fri, 15 Nov 2024 at 00:06, Laurent Pinchart wrote:
<snip>
>>>>> Is there any ACPI- or WMI-provided information that could assist with >>>>> associating a privacy GPIO with a camera ? > > I just realized I did not answer this question from Laurent > in my previous reply. > > No unfortunately there is no ACPI- or WMI-provided information that > could assist with associating ACPI/WMI camera privacy controls with > a specific camera. Note that these are typically not exposed as a GPIO, > but rather as some vendor firmware interface. > > Thinking more about this I'm starting to believe more and more > that the privacy-control stuff should be handled by libcamera > and then specifically by the pipeline-handler, with some helper > code to share functionality where possible. > > E.g. on IPU6 equipped Windows laptops there may be some ACPI/WMI > driver which provides a /dev/input/event# SW_CAMERA_LENS_COVER node.
Using an event device means that the user would need permissions to access it. Would distributions be able to tell the device apart from other event devices such as mouse/keyboard, where a logged user may not have permission to access all event devices in a multi-seat system ?
input events modaliases contain a lot of info, including what sort of events they report, e.g. :
[hans@shalem uvc]$ cat /sys/class/input/input36/modalias input:b0003v046Dp405Ee0111-e0,1,2,3,4,11,14,k71,72,73,74,75,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8E,8F,90,96,98,9B,9C,9E,9F,A1,A3,A4,A5,A6,A7,A8,A9,AB,AC,AD,AE,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,CC,CE,CF,D0,D1,D2,D4,D8,D9,DB,DF,E0,E1,E4,E5,E6,E7,E8,E9,EA,EB,F0,F1,F4,100,110,111,112,113,114,115,116,117,118,119,11A,11B,11C,11D,11E,11F,161,162,166,16A,16E,172,174,176,177,178,179,17A,17B,17C,17D,17F,180,182,183,185,188,189,18C,18D,18E,18F,190,191,192,193,195,197,198,199,19A,19C,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1AF,1B0,1B1,1B7,1BA,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,250,251,260,261,262,263,264,265,r0,1,6,8,B,C,a20,m4,l0,1,2,3,4,sfw
So I believe that we can create a udev rule which matches on input devices with SW_CAMERA_LENS_COVER functionality and set a uaccess tag on those just like it is done for /dev/video# nodes.
Or we can just use a specific input-device-name (sub) string and match on that.
This may require using a separate input_device with just the SW_CAMERA_LENS_COVER functionality in some of the laptop ACPI / WMI drivers, but that is an acceptable compromise IMHO.
As long as it's doable I'm OK with it.
(we don't want to report privacy sensitive input events on these nodes to avoid keylogging).
Would compositors be able to ignore the device to let libcamera handle it ?
input devices can be opened multiple times and we want the compositor to also open it to show camera on/off OSD icons / messages.
I'm not sure we want that though, as the event should be associated with a particular camera in messages. It would be better if it still went through libcamera and pipewire.
For OSD we do not necessarily need to know what camera the GPIO is associated with.
We just want to give instant feedback about a button on their device. Eg in ChromeOS we just say: "camera off" not "user facing camera off"
That may be true of Chrome OS, but in general, other systems may want to provide more detailed information. I wouldn't model the API and architecture just on Chrome OS.
It is not about ChromeOS, it is about the use case.
We were talking about 2 usecases:
- instant feedback for a button. Actor: OSD / composer
- this camera is disabled, please use other camera or enable it: Actor
camera app, or camera "service" (read pipewire, libcamera, or the permission handler for snap)
There are some examples showing that for "instant feedback" there is no need to link the event to the camera:
- there is hardware where this is not possible to establish the link.
- ChromeOS does not show the camera name (when it has enough
information to do so)
- I believe Hans mentioned that Windows does not show the camera name.
- (Hans, are you wiring SW_CAMERA_LENS_COVER to the user right now?)
Do you know of a system where this info is needed?
I would like to see this wired up in GNOME but I'm not aware of anyone actively working on this.
I expect that for GNOME a simple OSD with a camera icon with / without a cross through it will suffice and I expect such a simple implementation to directly talk to libinput at the compositor level.
If GNOME does ever wants to show a label on the OSD with a description of which camera it applies to, like it currently does for volume up/down/ mute keys which affect the current default sound output), then I would expect it to talk to pipewire to get the events instead of directly through libinput.
Either scenario can be supported with the SW_CAMERA_LENS_COVER userspace API, so IMHO this is an implementation detail which can be left up to whomever implements this for GNOME.
FWIW if I were to implement this myself I would go for the simple solution of not showing a camera description like ChromeOS is currently doing.
Regards,
Hans