Message-Id: <DAPQ9L3FCLIF.24FIDLQST2S1O@gmail.com>
Date: Wed, 18 Jun 2025 23:27:13 +0900
From: "Alexandre Courbot" <gnurou@...il.com>
To: "Mauro Carvalho Chehab" <mchehab+huawei@...nel.org>
Cc: "Albert Esteve" <aesteve@...hat.com>, "Michael S. Tsirkin"
 <mst@...hat.com>, "Mauro Carvalho Chehab" <mchehab@...nel.org>, "Hans
 Verkuil" <hverkuil@...all.nl>, "Jason Wang" <jasowang@...hat.com>, "Xuan
 Zhuo" <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, <gurchetansingh@...gle.com>,
 <daniel.almeida@...labora.com>, <adelva@...gle.com>,
 <changyeon@...gle.com>, <nicolas.dufresne@...labora.com>,
 <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
 <virtualization@...ts.linux.dev>
Subject: Re: [PATCH v3] media: add virtio-media driver

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@...nel.org> escreveu:
>
>> Em Tue, 17 Jun 2025 10:49:38 +0200
>> Mauro Carvalho Chehab <mchehab+huawei@...nel.org> escreveu:
>> 
>> > Hi Alex,
>> > 
>> > Em Tue, 27 May 2025 23:03:39 +0900
>> > Alexandre Courbot <gnurou@...il.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.

Powered by blists - more mailing lists