On Tue, Feb 03, 2026 at 03:19:13PM +0100, [email protected] wrote: > On 3-Feb-26 14:20, Jani Nikula wrote: > > On Tue, 03 Feb 2026, [email protected] wrote: > >> The problem is that what you're suggesting is basically a much > >> improved (using dma-buf is way better) v4l2-loopback driver and > >> v4l2-loopback has been blocked from getting merged into the kernel > >> because besides the mobile-phone camera use, the other main use-case > >> is to allow running proprietary camera stacks like Intel's proprietary > >> camerastack and then presenting that to userspace as a standard v4l2 > >> cam so that userspace apps will just work. > > > > ... > > > >> The community concensus is that the solution here is for apps to > >> access cameras through pipewire. Together with the shift of laptops > >> cameras from UVC to "raw" MIPI cameras there also is a shift to > >> running applications sandboxed as flatpacks because of the changing > >> "cyber" security landscape. This is why pipewire was chosen because > >> it also solves the accessing cameras from a sandbox issue. > > > > Why is v4l2-loopback problematic from the perspective of facilitating > > running proprietary camera stacks, but pipewire isn't? > > Once pipewire mostly works everywhere for camera access then indeed > this will allow proprietary stacks to present themselves as a pipewire src. > For now though most proprietary stacks seem to prefer v4l2loopback because > pipewire is not supported as camera source yet by a lot of apps.
I agree, that's a perfectly valid assessment of the situation. > As I indicated in my original email personally I'm a bit divided on > whether a virtual camera driver should be kept out of the kernel > to not promote proprietary userspace stacks, but this is not my call. Even disregarding that argument, the camera ecosystem is moving towards implementing those use cases entirely in userspace with PipeWire. I believe that merging a new kernel driver for this purpose, especially one that exposes a custom API on its sink side and would therefore require developing support in all source applications, goes against the direction we're taking overall. > OTHO evdi: https://github.com/DisplayLink/evdi has been kept out > of the kernel for pretty much the same reasons by the drm/kms folks. > > At least AFAIK there still is no way to present virtual kms capable > display outputs backed by userspace in the kernel. > > I completely understand where you're coming from wrt v4l2-loopback > support (or something equivalent) but asking for this really is > the same as asking for the evdi driver to get merged, which AFAIK > has been blocked for the reason of avoiding proprietary userspace > display output drivers (I guess there might be technical reasons too). -- Regards, Laurent Pinchart
