Hello, On Mon, Jan 02, 2023 at 01:14:15PM +0000, Sakari Ailus wrote: > On Wed, Dec 28, 2022 at 01:44:38AM +0000, Barnabás Pőcze wrote: > > On 2022. december 26., hétfő 10:52, Laurent Pinchart wrote: > > > On Fri, Dec 23, 2022 at 11:17:35PM +0000, Kieran Bingham wrote: > > > > > > > Provide a streaming attribute to allow userspace to interogate if a device > > > > is actively streaming or not. > > > > > > > > This will allow desktop notifications to report if a camera or device > > > > is active on the system, rather than just 'open' which can occur when > > > > configuring the device. > > > > > > > > Bug: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669 > > > > Signed-off-by: Kieran Bingham kieran.bingham@xxxxxxxxxxxxxxxx > > > > --- > > > > > > > > This is a quick POC to see if such a facility makes sense. > > > > I'm weary that not all video devices may have the queues registered on > > > > the struct video_device, but this seems like an effective way to be able > > > > to determine if a device is actively streaming on a system. > > > > > > I can imagine multiple problems, from race conditions to permissions and > > > privacy. In order to comment on the fitness of this solution to address > > > the problem you're trying to solve, could you describe the actual > > > problem ? > > > > The issue is explained in the following thread: > > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669#note_1697388 > > > > In short, the user wants to show a "camera-in-use" indicator when the laptop camera > > is used. The script that the user previously had only checked if /dev/video0 > > was open in any process, if it was, the indicator was shown. However, libcamera > > - at least at the moment - keeps the file descriptor open as long as the Camera > > object exists, which pipewire keeps alive for the entire lifetime of the device, > > therefore the "camera-in-use" indicator is always shown. > > A sysfs attribute is not a great way to address this. > > libcamera certainly has information on whether streaming is ongoing. The > information should come from there. Or Pipewire. Dbus perhaps? I tend to agree, I think this is best solved in userspace where PipeWire can have a centralized view of all cameras in the system, and of their users. > Alternatively libcamera could close the video devices while not streaming > but that would involve e.g. releasing possible video buffer allocations as > well, increasing streaming start latency. Closing video (and subdev) nodes when the camera is not in use would be good I think. It doesn't mean we have to open them when starting capture, explicit open/close operation (or similar, maybe introducing a capture session object in the libcamera API would also make sense, it should be considered as part of the same issue) could help with this. -- Regards, Laurent Pinchart
