Re: video(4) landed. "No webcam driver" is dead.

Because the world is not USB video cameras.

Abdelkader refactored the existing uvideo code into a framework we can
add other video sources to.

We don't have a way to run PCIe video cameras via userland. My macbook
intel hardware have PCIe video cameras.

We don't have a way to run firewire cameras via userland. Yeah it's
2026, but unlike USB we don't expose a "generic" device for firewire.

We don't have a way to run MIPI DSI video cameras via userland. The
SoCs all do that, so if we want camera on say a raspberry pi, we need
a userland camera.

The data rate of a 4k 60fps uncompressed video stream is measured in
gigabits/sec, not
megabits/sec. The target behavioural range for this hardware is no
longer a 640x480
video stream, nor does it assume a compressed video stream. If we want
to be able
to then loop this video feed inside the kernel into, say, some
hardware like an NPU, TPU
or ISP (image signal processor) then all the plumbing right now needs
to be in the kernel.

We do need that kernel API, because we don't have generic ways to
expose and potentially loop back
random devices, netgraph style, into and out of kernel/userland boundaries.



-adrian

On Tue, 11 Aug 2026 at 11:20, Gleb Popov <[email protected]> wrote:
>
> On Tue, Aug 11, 2026 at 12:43 PM Abdelkader Boudih <[email protected]> wrote:
> > The userland path was not removed , multimedia/webcamd  still works if you want the isolation tradeoff.
> > video(4) isnt a replacement for that option, its a shared framework for the kernel drivers.
> >
> > uvideo itself isn't new code we're taking a fresh risk on, it's OpenBSD driver port, in-kernel there since 2008 and ported by bapt.
> >
> > video(4) is that same logic factored out so uvideo, fwcam, and future capture drivers stop reimplementing their own buffer/mmap handling. Any crash bug in the core is a bug OpenBSD has been carrying for 15+ years, not one this change introduces and the review found several (UAF, lock ordering) that are now fixed upstream of both.
>
> This still doesn't answer the question why the usermode
> implementation shouldn't be preferred. For example, the
> tradeoffs of FUSE file systems are well-known, and for
> a given FS or use case we can decide which implementation,
> a kernel one or a usermode one, fits better.
>
> So what about video(4)?
>
> > With more non tech people moving from windows or macos to freebsd, having a "Plug'N'Play" experience is what we should aim for.
>
> If by "plug'n'play" you mean that there is no need to install
> an additional daemon from packages, then I view this as
> a purely distribution problem. We don't provide a graphical
> experience out of the box anyways.
>