On Mon, Jul 13, 2026 at 3:00 AM Albert Esteve <[email protected]> wrote: > > On Sun, Jul 12, 2026 at 9:10 AM Mauro Carvalho Chehab > <[email protected]> wrote: > > > > On Mon, 22 Jun 2026 16:43:35 -0400 > > Brian Daniels <[email protected]> wrote: > > > > > From: Alexandre Courbot <[email protected]> > > > > > > Add the first version of the virtio-media driver. > > > > > > This driver acts roughly as a V4L2 relay between user-space and the > > > virtio virtual device on the host, so it is relatively simple, yet > > > unconventional. It doesn't use VB2 or other frameworks typically used in > > > a V4L2 driver, and most of its complexity resides in correctly and > > > efficiently building the virtio descriptor chain to pass to the host, > > > avoiding copies whenever possible. This is done by > > > scatterlist_builder.[ch]. > > > > > > This version supports MMAP buffers, while USERPTR buffers can also be > > > enabled through a driver option. DMABUF support is still pending. > > > > In practice, USERPTR was used on several drivers that wanted to > > share buffers between V4L2 and GPU (so, a previous approach before > > DMABUF implementation). > > > > On my tests with this driver, I was unable use a 1080p camera with > > V4L2 and GPU on crossvm. Lower resolutions worked. No idea if this > > was a limitation of crossvm (I only used it to test this driver) > > or if it is due to a poor MMAP implementation. > >
I followed these instructions to test with crosvm on my wayland machine: https://crosvm.dev/book/devices/wayland.html Note that I built with `cargo build --features "gpu,media"`, not just `cargo build --features "gpu"` to ensure virtio-media was enabled. My crosvm command was as follows: ./crosvm/target/release/crosvm run \ linux_upstream/arch/x86/boot/bzImage \ --disable-sandbox \ --block old-debian-12.img \ -p "root=/dev/vda1" \ --net tap-name=crosvm_tap \ -m 8192 \ -c num-cores=16 \ -s /tmp/crosvm.sock \ --v4l2-proxy=/dev/video0 \ --gpu=context-types=cross-domain \ --wayland-sock $XDG_RUNTIME_DIR/wayland-0 \ --serial type=stdout,hardware=virtio-console,console=true,stdin=true The path to your kernel, block device image, and /dev/video* device may be different depending on your development setup. In the guest, I launched qv4l2 with the following command: sommelier --virtgpu-channel qv4l2 -platform wayland I had to disable OpenGL rendering under the "Capture" menu (otherwise the rendered window just showed up as white) but other than that it rendered 1080p smoothly using the MJPEG format. Here's a video showing 1080p working smoothly: https://www.youtube.com/watch?v=aw03pM_-7oA > > > > > Compliance Testing > > > > > > This was tested using v4l2-compliance. Since virtio-media serves as > > > a proxy to host devices for the guest VMs, we expect the guest > > > compliance test to essentially match the host compliance test for the > > > same device. > > > > > > NOTE: v4l2-compliance changes its test behavior depending on the driver > > > name. In the guest, the driver name for virtio-media proxied-devices is > > > always "virtio-media", even if the actual host device has a driver name > > > of e.g. "uvcvideo". To ensure the test is consistent between the host > > > and the guest, I created a patch for the v4l2-compliance tool that > > > allows you to override the driver name. All test results that follow use > > > this patch: > > > https://lore.kernel.org/r/[email protected]/ > > > > As mentioned before, please submit this with their rationale in > > separate as a [PATCH v4l-utils] to linux-media ML. Sounds good, let's continue the discussion on my existing [PATCH v4l-utils] thread: https://lore.kernel.org/all/[email protected]/ > > > > > > All tests used a Logitech USB Webcam C925e. > > > > Please test it displaying inside crossvm - or even better to QEMU if > > you manage to add virtio-media support to it. > > > > Being at QEMU makes a lot easier for everyone to test it. > > Hi, > > Regarding the QEMU support mention, I created this series in QEMU to > add the virtio-media PCI device: > https://lore.kernel.org/all/[email protected]/ > > Testing was done using an older driver version at > https://github.com/chromeos/virtio-media/tree/main/driver as described > in the cover letter. But I can try testing it with this series. Either > way, the procedure for using QEMU is in the cover letter, so anyone > can try it. If you'd be able to test again with this series and post your results that would be great, thanks Albert! > BR, > Albert. > > > > > > > Thanks, > > Mauro > > >
