qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [RFC] Proposal for a QEMU video subsystem for cameras and webcam


From: zhenwei pi
Subject: Re: Re: [RFC] Proposal for a QEMU video subsystem for cameras and webcams
Date: Tue, 11 Mar 2025 19:19:44 +0800
User-agent: Mozilla Thunderbird



On 3/11/25 00:57, Thomas Huth wrote:
On 10/03/2025 17.51, Alex Bennée wrote:
David Milosevic <david.milosevic@9elements.com> writes:

Dear QEMU Developers,

I would like to propose the development of a video subsystem in QEMU, with the initial implementation focusing on UVC video device emulation and support for multiple
backends, including V4L2, GStreamer, and libcamera.

This work is already in progress at 9elements, and we would like to upstream it.

== Motivation

Currently, USB pass-through is the only way to make video devices available to guests, which

     - excludes non-USB cameras (e.g., MIPI)
     - performs poorly with high-resolution cameras
     - does not work with USB 3.0 video devices (Issue #1613)

== Proposal

We aim to introduce a video subsystem in QEMU that allows for the implementation of various video devices, similar to how QEMU handles audio. The first device implementation will be UVC (USB Video Class) device emulation, with support for multiple backends. Future extensions
could include virtio-video or other PCI-based video devices.

Are you aware of virtio-media? It was an alternative proposal to
virtio-video which effectively becomes an encapsulation of v4l to the
guest.

... but USB video would also be nice, wouldn't it? That could enable guests to use webcams without needing additional virtio drivers for it, I think?


Agree. UVC based hardware emulation does not need additional guest driver, and it may help guest kernel driver debug. It's also useful for USB video related education.

Virtio based hardware will use the common video/camera framework, this is also another good shape: hardware devices emulation -> generic framework -> multiple backend driver implement.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]