mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: "Alexandre Courbot" <gnurou@gmail.com>
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 17:05:00 +0200	[thread overview]
Message-ID: <20250618170500.1e60aacf@sal.lan> (raw)
In-Reply-To: <DAPQ9L3FCLIF.24FIDLQST2S1O@gmail.com>

Em Wed, 18 Jun 2025 23:27:13 +0900
"Alexandre Courbot" <gnurou@gmail.com> escreveu:

> 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.

It was actually easier than what I expected, but it had to run
as root. Due to that, I had to move it to a test machine that I
use just for such kind of tests. I updated it to the Ubuntu 
version 24.10, but crossvm refused to build even. I end needing
to install rust via rustup, as only version 1.81.0 had what it is
required to run with the needed features (network, media and gpu).

> >> > 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.

In the specific case of a virtio driver, while it is OK for the first
versions to support MMAP only, USERPTR support could make sense, as 
this is not a real driver for a certain hardware, but instead it is
replicating at the guest whatever the host driver has, which may or
may not have MMAP.

That's said, I don't recall any driver with USERPTR and without MMAP
those days. I did a quick check: VB2 devices always seem to have MMAP.

-

There is one case where only read ioctl is supported: pvrusb2, which
is probably not interesting enough those days, but IMHO, for the few
cases where a device can't be used at the guest due to the lack of a 
compatible streaming API, virtio-media should not expose it to the
guest and/or issue an error or warning.

> 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.

Makes sense.

I'll do some tests later and check how it works with
a GUI app and some real devices.

Regards,
Mauro

  reply	other threads:[~2025-06-18 15:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-12  4:08 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
2025-06-18 15:05                     ` Mauro Carvalho Chehab [this message]
2025-06-20 12:03                       ` Alexandre Courbot
2025-09-08 10:03                         ` Mauro Carvalho Chehab
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
2025-09-09  9:12 ` Mauro Carvalho Chehab
2026-05-29 16:03   ` Brian Daniels
2026-07-12  6:30     ` Mauro Carvalho Chehab

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=20250618170500.1e60aacf@sal.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=adelva@google.com \
    --cc=aesteve@redhat.com \
    --cc=changyeon@google.com \
    --cc=daniel.almeida@collabora.com \
    --cc=eperezma@redhat.com \
    --cc=gnurou@gmail.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@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