All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [PATCH v2 3/3] uvcvideo: add a metadata device node
Date: Tue, 06 Dec 2016 17:56:28 +0200	[thread overview]
Message-ID: <6827808.RfcVLAN17o@avalon> (raw)
In-Reply-To: <Pine.LNX.4.64.1612061127550.17179@axis700.grange>

Hi Guennadi,

On Tuesday 06 Dec 2016 11:39:22 Guennadi Liakhovetski wrote:
> On Tue, 6 Dec 2016, Laurent Pinchart wrote:
> > On Monday 05 Dec 2016 23:13:53 Guennadi Liakhovetski wrote:
> >> On Tue, 6 Dec 2016, Laurent Pinchart wrote:
> >>>>>> +	/*
> >>>>>> +	 * Register a metadata node. TODO: shall this only be enabled
> >>>>>> for some
> >>>>>> +	 * cameras?
> >>>>>> +	 */
> >>>>>> +	if (!(dev->quirks & UVC_QUIRK_BUILTIN_ISIGHT))
> >>>>>> +		uvc_meta_register(stream);
> >>>>>> +
> >>>>> 
> >>>>> I think so, only for the cameras that can produce metadata.
> >>>> 
> >>>> Every UVC camera produces metadata, but most cameras only have standard
> >>>> fields there. Whether we should stream standard header fields from the
> >>>> metadata node will be discussed later. If we do decide to stream
> >>>> standard header fields, then every USB camera gets metadata nodes. If
> >>>> we decide not to include standard fields, how do we know whether the
> >>>> camera has any private fields in headers without streaming from it? Do
> >>>> you want a quirk for such cameras?
> >>> 
> >>> Unless they can be detected in a standard way that's probably the best
> >>> solution. Please remember that the UVC specification doesn't allow
> >>> vendors to extend headers in a vendor-specific way.
> >> 
> >> Does it not? Where is that specified? I didn't find that anywhere.
> > 
> > It's the other way around, it document a standard way to extend the
> > payload header. Any option you pick risks being incompatible with future
> > revisions of the specification. For instance the payload header's
> > bmHeaderInfo field can be extended through the use of the EOF bit, but a
> > future version of the specification could also extend it, in a way that
> > would make a vendor-specific extension be mistaken for the standard
> > extension.
> > 
> > Now, you could add data after the standard payload without touching the
> > bmHeaderInfo field, but I'm still worried it could be broken by future
> > versions of the specification.
> 
> Exactly - using "free" space in payload headers is not a part of the spec,
> but is also not prohibited by it. As for future versions - cameras specify
> which version of the spec they implement, and existing versions cannot
> change. If a camera decides to upgrade and in future UVC versions there
> won't be enough space left for the private data, only then the camera
> manufacturer will have a problem, that they will have to solve. The
> user-space software will have to know, that UVC 5.1 metadata has a
> different format, than UVC 1.5, that's true.

I agree that the specification doesn't explicitly forbid it, but it's a very 
grey area. An extension mechanism should be standardized by the USB-IF UVC 
working group. I'd propose it myself if they hadn't decided to kick me out 
years ago :-)

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2016-12-06 15:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 11:28 [PATCH 0/3] uvcvideo: a cosmetic fix and 2 new features Guennadi Liakhovetski
2016-06-24 11:28 ` [PATCH 1/3] uvcvideo: initialise the entity function field Guennadi Liakhovetski
2016-06-24 13:26   ` Laurent Pinchart
2016-06-24 11:29 ` [PATCH 2/3] uvcvideo: send a control event when a Control Change interrupt arrives Guennadi Liakhovetski
2016-06-24 11:29 ` [PATCH 3/3] uvcvideo: add a metadata device node Guennadi Liakhovetski
2016-06-24 12:46   ` kbuild test robot
2016-06-24 13:12   ` kbuild test robot
2016-12-02 10:53   ` [PATCH v2 " Guennadi Liakhovetski
2016-12-05 10:53     ` Laurent Pinchart
2016-12-05 15:35       ` Guennadi Liakhovetski
2016-12-05 22:06         ` Laurent Pinchart
2016-12-05 22:13           ` Guennadi Liakhovetski
2016-12-05 22:25             ` Laurent Pinchart
2016-12-06 10:39               ` Guennadi Liakhovetski
2016-12-06 15:56                 ` Laurent Pinchart [this message]
2016-12-08 13:34                   ` Guennadi Liakhovetski
2016-12-08 13:39                     ` Laurent Pinchart
2016-12-08 15:18                       ` Guennadi Liakhovetski

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=6827808.RfcVLAN17o@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.