From: Albert Esteve <aesteve@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Alexandre Courbot" <acourbot@google.com>,
virtio-comment@lists.oasis-open.org,
virtio-dev@lists.oasis-open.org,
"Alex Bennée" <alex.bennee@linaro.org>,
"Andrew Gazizov" <andrew.gazizov@opensynergy.com>,
"Andrii Cherniavskyi" <andrii.cherniavskyi@opensynergy.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Enric Balletbo i Serra" <eballetb@redhat.com>,
"Enrico Granata" <egranata@google.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.com>,
"Keiichi Watanabe" <keiichiw@chromium.org>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Alexander Gordeev" <alexander.gordeev@opensynergy.com>,
"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
"Peter Griffin" <peter.griffin@linaro.org>,
"Tomasz Figa" <tfiga@chromium.org>,
"Matti Möll" <Matti.Moell@opensynergy.com>
Subject: [virtio-dev] Re: virtio-v4l2 specification draft
Date: Thu, 6 Jul 2023 10:27:19 +0200 [thread overview]
Message-ID: <CADSE00KRu3b94kZMVV4XMqA=rTFKGSZ1fK=orN71P9PTSFCZvg@mail.gmail.com> (raw)
In-Reply-To: <20230531020611-mutt-send-email-mst@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]
Hi Alex,
Sorry for the late reply. I think this is a nice solution, specially for
the host-guest
memory management part. I was intrigued with how would you solve this, as
the v4l2 struct memory fields can't be directly used.
In that sense, sending a field that is going to be ignored by both driver
and device,
feels like kindof a waste. But I guess there is not a good solution to that.
Have you considered avoiding using struct v4l2_buffer for QBUF and DQBUF
ioctls,
and having virtio-v4l2 specific struct for them? The device would have the
burden to
copy the all the fields and leave the `m` field out, so it may have its own
downsides.
In any case, the specs are short and clear to follow. Great work!
I just have a couple comments/questions:
- The text in `0.1.6.3` and `0.1.6.3.1` is saying the same thing twice (?).
Maybe would be
clearer to unify?
- If I understood correctly, the `stream_id` is assigned by the device
after receiving
a VIRTIO_V4L2_CMD_OPEN? Is it supposed to be a correlative natural number
(1, 2, etc.)?
I assume that after (successfully) closing the stream, its stream_id can
be reused?
- For section `0.1.6.7` I think it would be good to refer (again) to the
section `0.1.6.5` so that
we can quickly navigate to the section that explains the memory fields in
the presented events.
Best regards,
Albert
On Wed, May 31, 2023 at 8:08 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> On Wed, May 31, 2023 at 03:02:04PM +0900, Alexandre Courbot wrote:
> > Hello everyone,
> >
> > With the virtio-video call taking place soon, I thought it would help
> > everyone understand both proposals if I sent a more formal
> > specification of what virtio-v4l2 looks like. Please find it attached
> > to this email.
> >
> > I apologize for not finishing and sending this earlier, but hopefully
> > at 7 and a half pages it should be rather quick to skim through. :)
> >
> > Despite its short size, this spec is capable of supporting camera and
> > image processor devices (on top of decoder/encoders), and also allows
> > for another kind of memory backing for buffers (host-managed) that is
> > not supported by virtio-video.
> >
> > For convenience I have made use of clickable links to the relevant
> > parts of the V4L2 documentation, since it is supposed to be used
> > alongside this spec.
> >
> > Looking forward to a fruitful discussion tomorrow!
> >
> > Cheers,
> > Alex.
>
>
> Can you please post patch with tex source inline as opposed as
> pdf as an attachment? Thanks!
>
> --
> MST
>
>
[-- Attachment #2: Type: text/html, Size: 3307 bytes --]
prev parent reply other threads:[~2023-07-06 8:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPBb6MXBaKKFGg8Yt2Me8kjUwCm4utWcsVOiCS1Qunjhza4Ycg@mail.gmail.com>
2023-05-31 6:07 ` [virtio-dev] Re: virtio-v4l2 specification draft Michael S. Tsirkin
2023-07-06 8:27 ` Albert Esteve [this message]
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='CADSE00KRu3b94kZMVV4XMqA=rTFKGSZ1fK=orN71P9PTSFCZvg@mail.gmail.com' \
--to=aesteve@redhat.com \
--cc=Matti.Moell@opensynergy.com \
--cc=acourbot@google.com \
--cc=alex.bennee@linaro.org \
--cc=alexander.gordeev@opensynergy.com \
--cc=andrew.gazizov@opensynergy.com \
--cc=andrii.cherniavskyi@opensynergy.com \
--cc=cohuck@redhat.com \
--cc=daniel.almeida@collabora.com \
--cc=eballetb@redhat.com \
--cc=egranata@google.com \
--cc=gustavo.padovan@collabora.com \
--cc=keiichiw@chromium.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=mst@redhat.com \
--cc=peter.griffin@linaro.org \
--cc=tfiga@chromium.org \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).