From: "Alexandre Courbot" <gnurou@gmail.com>
To: "Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>
Cc: "Albert Esteve" <aesteve@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Jason Wang" <jasowang@redhat.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
gurchetansingh@google.com, daniel.almeida@collabora.com,
adelva@google.com, changyeon@google.com,
nicolas.dufresne@collabora.com, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, virtualization@lists.linux.dev
Subject: Re: [PATCH v3] media: add virtio-media driver
Date: Wed, 18 Jun 2025 23:27:13 +0900 [thread overview]
Message-ID: <DAPQ9L3FCLIF.24FIDLQST2S1O@gmail.com> (raw)
In-Reply-To: <20250617122034.3e570b4e@foz.lan>
On Tue Jun 17, 2025 at 7:20 PM JST, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Jun 2025 11:03:18 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>
>> Em Tue, 17 Jun 2025 10:49:38 +0200
>> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
>>
>> > Hi Alex,
>> >
>> > Em Tue, 27 May 2025 23:03:39 +0900
>> > Alexandre Courbot <gnurou@gmail.com> escreveu:
>> >
>> > > > > > Btw, I was looking at:
>> > > > > >
>> > > > > > https://github.com/chromeos/virtio-media
>> > > > > >
>> > > > > > (I'm assuming that this is the QEMU counterpart, right?)
>> > > > >
>> > > > > crosvm actually, but QEMU support is also being worked on.
>> > > >
>> > > > Do you have already QEMU patches? The best is to have the Kernel driver
>> > > > submitted altogether with QEMU, as Kernel developers need it to do the
>> > > > tests. In my case, I never use crosvm, and I don't have any Chromebook
>> > > > anymore.
>> > >
>> > > IIRC Albert Esteve was working on this, maybe he can share the current status.
>> >
>> > Any news regards to it?
>> >
>> > > Note that crosvm does not require a Chromebook, you can build and run
>> > > it pretty easily on a regular PC. I have put together a document to
>> > > help with that:
>> > >
>> > > https://github.com/chromeos/virtio-media/blob/main/TRY_IT_OUT.md
>> >
>> > I started looking on it today. Already installed crossvm (I had to
>> > install libcap-devel to build it). Still, I'm not familiar with
>> > crossvm, which is a little be painful. In particular, how can I
>> > enable network on it and speedup it? With suggested parameters,
>> > it picked only one CPU, and very few memory on it:
>> >
>> > # cat /proc/cpuinfo|grep processor
>> > processor : 0
>> >
>> > # free
>> > total used free shared buff/cache available
>> > Mem: 221876 34780 139712 272 56096 187096
>> > Swap: 0 0 0
>> >
>> > I'd like to be able to compile things on it and use ssh/scp. So,
>> > the VM needs more CPUs, more memory, more network and GPU.
>
> Found how to setup cpus and memory, but didn't find a way to setup
> network without running it as root. The gpu parameter has several
> options. Not sure what backend works well for media apps like qv4l2,
> camorama, X11, ...
I'm afraid getting GPU and graphics in general to work is more involved
and tricky on a regular Linux setup (crosvm was primarily designed for
ChromeOS). If you really need it I can do some more research; most of my
tests have been done using v4l2-ctl or ffmpeg and saving the output on
disk for later inspection.
>
>> >
>> > Btw, on a quick test with v4l2-compliance, something looks weird:
>> > I started a camera application at the host. Still, v4l2-compliance
>> > said successfully excecuted mmap:
>> >
>> > Streaming ioctls:
>> > test read/write: OK (Not Supported)
>> > test blocking wait: OK
>> > test MMAP (no poll): OK
>> > test MMAP (select): OK
>> > Vide[2025-06-17T08:44:49.177972817+00:00 ERROR virtio_media::ioctl] VIDIOC_REQBUFS: memory type DmaBuf is currently unsupported
>> > [2025-06-17T08:44:49.178164554+00:00 ERROR virtio_media::ioctl] VIDIOC_REQBUFS: memory type DmaBuf is currently unsupported
>> > o Capturtest MMAP (epoll): OK
>> > test USERPTR (no poll): OK (Not Supported)
>> > test USERPTR (select): OK (Not Supported)
>> > test DMABUF (no poll): OK (Not Supported)
>> > test DMABUF (select): OK (Not Supported)
>> >
>> > Which doesn't make any sense, as the host OS should not allow access
>> > to mmap while streaming.
>>
>> Ah, this was with the "simple" device, not with the proxy one.
>> With the proxy one, I'm getting:
>>
>> # v4l2-ctl --all
>> Driver Info:
>> Driver name : virtio-media
>> Card type : usb video: usb video
>> Bus info : platform:virtio-media
>> Driver version : 6.15.0
>> Capabilities : 0x84200001
>> Video Capture
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps : 0x04200001
>> Video Capture
>> Streaming
>> Extended Pix Format
>> Priority: 2
>> Video input : 0 (Camera 1: ok)
>> Format Video Capture:
>> Width/Height : 1280/720
>> Pixel Format : 'MJPG' (Motion-JPEG)
>> Field : None
>> Bytes per Line : 0
>> Size Image : 1843200
>> Colorspace : sRGB
>> Transfer Function : Rec. 709
>> YCbCr/HSV Encoding: ITU-R 601
>> Quantization : Default (maps to Full Range)
>> Flags :
>> Crop Capability Video Capture:
>> Bounds : Left 0, Top 0, Width 1280, Height 720
>> Default : Left 0, Top 0, Width 1280, Height 720
>> Pixel Aspect: 1/1
>> Selection Video Capture: crop_default, Left 0, Top 0, Width 1280, Height 720, Flags:
>> Selection Video Capture: crop_bounds, Left 0, Top 0, Width 1280, Height 720, Flags:
>> Streaming Parameters Video Capture:
>> Capabilities : timeperframe
>> Frames per second: 30.000 (30/1)
>> Read buffers : 0
>>
>> User Controls
>>
>> brightness 0x00980900 (int) : min=-128 max=127 step=1 default=-11 value=-11
>> contrast 0x00980901 (int) : min=0 max=255 step=1 default=148 value=148
>> saturation 0x00980902 (int) : min=0 max=255 step=1 default=180 value=180
>> hue 0x00980903 (int) : min=-128 max=127 step=1 default=0 value=0
>>
>> # v4l2-compliance -d0 -s
>>
>> Streaming ioctls:
>> test read/write: OK (Not Supported)
>> test blocking wait: OK
>> fail: v4l2-test-buffers.cpp(1345): node->streamon(q.g_type()) != EINVAL
>> test MMAP (no poll): FAIL
>> fail: v4l2-test-buffers.cpp(1345): node->streamon(q.g_type()) != EINVAL
>> test MMAP (select): FAIL
>> fail: v4l2-test-buffers.cpp(1345): node->streamon(q.g_type()) != EINVAL
>> test MMAP (epoll): FAIL
>> test USERPTR (no poll): OK (Not Supported)
>> test USERPTR (select): OK (Not Supported)
>> [2025-06-17T08:55:20.768760714+00:00 ERROR virtio_media::ioctl] VIDIOC_REQBUFS: memory type DmaBuf is currently unsupported
>> test DMABUF (no poll): OK (Not Supported)
>> [2025-06-17T08:55:20.769745707+00:00 ERROR virtio_media::ioctl] VIDIOC_REQBUFS: memory type DmaBuf is currently unsupported
>> test DMABUF (select): OK (Not Supported)
>>
>> At the host, I'm getting:
>>
>> Streaming ioctls:
>> test read/write: OK (Not Supported)
>> test blocking wait: OK
>> fail: ../utils/v4l2-compliance/v4l2-test-buffers.cpp(1346): node->streamon(q.g_type()) != EINVAL
>> test MMAP (no poll): FAIL
>> fail: ../utils/v4l2-compliance/v4l2-test-buffers.cpp(1346): node->streamon(q.g_type()) != EINVAL
>> test MMAP (select): FAIL
>> fail: ../utils/v4l2-compliance/v4l2-test-buffers.cpp(1346): node->streamon(q.g_type()) != EINVAL
>> test MMAP (epoll): FAIL
>> test USERPTR (no poll): OK
>> test USERPTR (select): OK
>> test DMABUF: Cannot test, specify --expbuf-device
These logs look ok to me: the MMAP tests are failing on the host, so
they are also expected to fail on the guest (still I expect regular
streaming to work on both). USERPTR is not supported on the guest, as
per your request to not support this memory type in new drivers. DMABUF
is not supported at all at the moment.
If the host cannot pass compliance, the guest will inevitably suffer
from the same shortcomings. :) But at least on the devices I tested I
was still able to stream something onto the disk and the result was
correct.
next prev parent reply other threads:[~2025-06-18 14:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 4:08 [PATCH v3] media: add virtio-media driver Alexandre Courbot
2025-04-12 14:27 ` Markus Elfring
2025-05-26 12:13 ` Mauro Carvalho Chehab
2025-05-27 6:14 ` Alexandre Courbot
2025-05-27 9:13 ` Mauro Carvalho Chehab
2025-05-27 13:21 ` Alexandre Courbot
2025-05-27 13:35 ` Mauro Carvalho Chehab
2025-05-27 14:03 ` Alexandre Courbot
2025-05-27 14:42 ` Mauro Carvalho Chehab
2025-06-17 8:49 ` Mauro Carvalho Chehab
2025-06-17 9:03 ` Mauro Carvalho Chehab
2025-06-17 10:20 ` Mauro Carvalho Chehab
2025-06-18 14:27 ` Alexandre Courbot [this message]
2025-06-18 15:05 ` Mauro Carvalho Chehab
2025-06-20 12:03 ` Alexandre Courbot
2025-06-18 14:16 ` Alexandre Courbot
2025-06-18 14:40 ` Mauro Carvalho Chehab
2025-05-27 14:23 ` Michael S. Tsirkin
2025-05-27 14:39 ` Mauro Carvalho Chehab
2025-05-27 15:06 ` Michael S. Tsirkin
2025-05-28 11:07 ` Alexandre Courbot
2025-05-28 16:23 ` Ricardo Ribalda
2025-06-01 9:34 ` Mauro Carvalho Chehab
2025-06-01 10:01 ` Ricardo Ribalda
2025-07-24 17:24 ` Mauro Carvalho Chehab
2025-07-28 11:51 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DAPQ9L3FCLIF.24FIDLQST2S1O@gmail.com \
--to=gnurou@gmail.com \
--cc=adelva@google.com \
--cc=aesteve@redhat.com \
--cc=changyeon@google.com \
--cc=daniel.almeida@collabora.com \
--cc=eperezma@redhat.com \
--cc=gurchetansingh@google.com \
--cc=hverkuil@xs4all.nl \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mchehab@kernel.org \
--cc=mst@redhat.com \
--cc=nicolas.dufresne@collabora.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).