Re: Webcamd future

> I think much of the efforts in this area have gone towards base system 
> integration, ie video(4) and uvideo(4). These are present and under 
> active development in -CURRENT.
> 
> -- 
> Charlie Li
> ...nope, still don't have an exit line.
> 
> 
> 
Hi there,

I was part of the effort that brought `uvideo(4)` and `video(4)` to FreeBSD. The kernel code originally comes from OpenBSD, and we have been extending it on the FreeBSD side.

We now have a native video stack that handles capture and already exposes many standard UVC controls.

I think the next step should be an userland layer for controlling the camera as a device.

Modern cameras can expose much more than a single video stream. Userland should be able to handle things such as:
 • opening and closing a physical privacy shutter
 • switching between camera modes
 • controlling IR emitters, LEDs, focus, zoom, and other features
 • selecting and coordinating multiple sensors exposed as one camera
 • RGB + IR or RGB + depth cameras
 • thermal cameras
 • UVC extension units and vendor-specific controls
Thermal cameras are an interesting case. Some expose something that looks like an ordinary video stream, but the pixels may actually represent temperature measurements instead of colors. The device may also provide calibration data, temperature ranges, emissivity settings, shutter calibration, or a separate visible-light sensor. We should not have all those quirks in the kernel side.

That also gives us ability to  handle cameras where several physical sensors appear as one logical device without pushing all of that policy into the kernel. I remember some Logitech conference cameras have eyes that look like fly eyes but still show as 1 camera.

But instead of creating a new binary, we can modify webcamd to have new part with BSD code only.  So in 16+ it will compile only the new part.

Nicolas , don't hesitate to  reach out if you need help. I also like the idea of having the project moved to a neutral org owned by the foundation .. freebsd-contrib ?
We can reach out to Github to make the move.