Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

Hi Laurent,

On Fri, 30 Dec 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Friday 30 Dec 2016 14:04:34 Guennadi Liakhovetski wrote:
> > On Fri, 30 Dec 2016, Laurent Pinchart wrote:
> > > On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> > >> Hi Laurent,
> > >> 
> > >> I'd like to discuss extending this patch a bit, preferably as an
> > >> incremental patch.
> > >> 
> > >> First let me confirm my current understanding of the way the UVC driver
> > >> creates its media device topology. Do I understand it correctly, that
> > >> the driver allocates UVC entities (not media controller entities) for all
> > >> UVC units and terminals, but then uses subdevices for all such UVC
> > >> entities, except terminals, i.e. only for UVC units? struct uvc_entity
> > >> has an embedded struct v4l2_subdev object, but it's unused for UVC
> > >> terminals. Instead terminals are associated to video devices, which are
> > >> then linked into the MC topology? Is this my understanding correct?
> > > 
> > > That's correct, but looking at the code now, I think the driver should use
> > > a struct media_entity directly instead of a struct v4l2_subdev as it
> > > doesn't need any of the infrastructure provided by subdevs.
> > > 
> > >> I have a problem with the current version of this patch, that there is
> > >> no way to associate video device nodes with respepctive metadata nodes.
> > >> Would it be acceptable to use an MC link for this association?
> > > 
> > > No, links describe data connections.
> > 
> > Well, it is data - it's metadata, extracted from USB buffers.

A further argument to this cause: currently the metadata node isn't 
connected to anything, it's "floating freely," which is wrong too. It does 
stream data and we have to bind it somewhere. I see 2 possibilities: 
either link them to the same entity, as the actual video data, adding more 
endpoints to it, or link them to video nodes. The latter way would allow 
for easy matching. If we use the former approach, we could still agree to 
have pad #2*n and #2*n+1 to be matching video and metadata pads, but that 
would be less straight-forward.

Thanks
Guennadi

> > >> Is it allowed for video device MC entities to have source pads
> > >> additionally to their (usually single) sink pad(s) (in case of input
> > >> video devices)? If that would be acceptable, I could create an additional
> > >> patch to add a source pad to output terminal video nodes to link it to
> > >> metadata nodes.
> > > 
> > > That's a hack, I don't think it's a good idea.
> > 
> > Ok, would a completely specialised one-off sysfs solution be better? Maybe
> > a link under the metadata node to the main node?
> 
> Come on, I know you're better than that. Stop thinking short term about the 
> quickest hack that can provide the feature you need.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Laurent Pinchart]

Hi Guennadi,

On Friday 30 Dec 2016 14:04:34 Guennadi Liakhovetski wrote:
> On Fri, 30 Dec 2016, Laurent Pinchart wrote:
> > On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> >> Hi Laurent,
> >> 
> >> I'd like to discuss extending this patch a bit, preferably as an
> >> incremental patch.
> >> 
> >> First let me confirm my current understanding of the way the UVC driver
> >> creates its media device topology. Do I understand it correctly, that
> >> the driver allocates UVC entities (not media controller entities) for all
> >> UVC units and terminals, but then uses subdevices for all such UVC
> >> entities, except terminals, i.e. only for UVC units? struct uvc_entity
> >> has an embedded struct v4l2_subdev object, but it's unused for UVC
> >> terminals. Instead terminals are associated to video devices, which are
> >> then linked into the MC topology? Is this my understanding correct?
> > 
> > That's correct, but looking at the code now, I think the driver should use
> > a struct media_entity directly instead of a struct v4l2_subdev as it
> > doesn't need any of the infrastructure provided by subdevs.
> > 
> >> I have a problem with the current version of this patch, that there is
> >> no way to associate video device nodes with respepctive metadata nodes.
> >> Would it be acceptable to use an MC link for this association?
> > 
> > No, links describe data connections.
> 
> Well, it is data - it's metadata, extracted from USB buffers.
> 
> >> Is it allowed for video device MC entities to have source pads
> >> additionally to their (usually single) sink pad(s) (in case of input
> >> video devices)? If that would be acceptable, I could create an additional
> >> patch to add a source pad to output terminal video nodes to link it to
> >> metadata nodes.
> > 
> > That's a hack, I don't think it's a good idea.
> 
> Ok, would a completely specialised one-off sysfs solution be better? Maybe
> a link under the metadata node to the main node?

Come on, I know you're better than that. Stop thinking short term about the 
quickest hack that can provide the feature you need.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

On Fri, 30 Dec 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> > Hi Laurent,
> > 
> > I'd like to discuss extending this patch a bit, preferably as an
> > incremental patch.
> > 
> > First let me confirm my current understanding of the way the UVC driver
> > creates its media device topology. Do I understand it correctly, that the
> > driver allocates UVC entities (not media controller entities) for all UVC
> > units and terminals, but then uses subdevices for all such UVC entities,
> > except terminals, i.e. only for UVC units? struct uvc_entity has an
> > embedded struct v4l2_subdev object, but it's unused for UVC terminals.
> > Instead terminals are associated to video devices, which are then linked
> > into the MC topology? Is this my understanding correct?
> 
> That's correct, but looking at the code now, I think the driver should use a 
> struct media_entity directly instead of a struct v4l2_subdev as it doesn't 
> need any of the infrastructure provided by subdevs.
> 
> > I have a problem with the current version of this patch, that there is no
> > way to associate video device nodes with respepctive metadata nodes. Would
> > it be acceptable to use an MC link for this association?
> 
> No, links describe data connections.

Well, it is data - it's metadata, extracted from USB buffers.

> > Is it allowed for video device MC entities to have source pads additionally
> > to their (usually single) sink pad(s) (in case of input video devices)? If
> > that would be acceptable, I could create an additional patch to add a source
> > pad to output terminal video nodes to link it to metadata nodes.
> 
> That's a hack, I don't think it's a good idea.

Ok, would a completely specialised one-off sysfs solution be better? Maybe 
a link under the metadata node to the main node?

Thanks
Guennadi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Laurent Pinchart]

Hi Guennadi,

On Friday 30 Dec 2016 11:43:02 Guennadi Liakhovetski wrote:
> Hi Laurent,
> 
> I'd like to discuss extending this patch a bit, preferably as an
> incremental patch.
> 
> First let me confirm my current understanding of the way the UVC driver
> creates its media device topology. Do I understand it correctly, that the
> driver allocates UVC entities (not media controller entities) for all UVC
> units and terminals, but then uses subdevices for all such UVC entities,
> except terminals, i.e. only for UVC units? struct uvc_entity has an
> embedded struct v4l2_subdev object, but it's unused for UVC terminals.
> Instead terminals are associated to video devices, which are then linked
> into the MC topology? Is this my understanding correct?

That's correct, but looking at the code now, I think the driver should use a 
struct media_entity directly instead of a struct v4l2_subdev as it doesn't 
need any of the infrastructure provided by subdevs.

> I have a problem with the current version of this patch, that there is no
> way to associate video device nodes with respepctive metadata nodes. Would
> it be acceptable to use an MC link for this association?

No, links describe data connections.

> Is it allowed for video device MC entities to have source pads additionally
> to their (usually single) sink pad(s) (in case of input video devices)? If
> that would be acceptable, I could create an additional patch to add a source
> pad to output terminal video nodes to link it to metadata nodes.

That's a hack, I don't think it's a good idea.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[Guennadi Liakhovetski]

Hi Laurent,

I'd like to discuss extending this patch a bit, preferably as an 
incremental patch.

First let me confirm my current understanding of the way the UVC driver 
creates its media device topology. Do I understand it correctly, that the 
driver allocates UVC entities (not media controller entities) for all UVC 
units and terminals, but then uses subdevices for all such UVC entities, 
except terminals, i.e. only for UVC units? struct uvc_entity has an 
embedded struct v4l2_subdev object, but it's unused for UVC terminals. 
Instead terminals are associated to video devices, which are then linked 
into the MC topology? Is this my understanding correct?

I have a problem with the current version of this patch, that there is no 
way to associate video device nodes with respepctive metadata nodes. Would 
it be acceptable to use an MC link for this association? Is it allowed for 
video device MC entities to have source pads additionally to their 
(usually single) sink pad(s) (in case of input video devices)? If that 
would be acceptable, I could create an additional patch to add a source 
pad to output terminal video nodes to link it to metadata nodes.

Thanks
Guennadi

On Mon, 12 Dec 2016, Guennadi Liakhovetski wrote:

> From: Guennadi Liakhovetski 
> 
> Some UVC video cameras contain metadata in their payload headers. This
> patch extracts that data, skipping the standard part of the header, on
> both bulk and isochronous endpoints and makes it available to the user
> space on a separate video node, using the V4L2_CAP_META_CAPTURE
> capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. Even
> though different cameras will have different metadata formats, we use
> the same V4L2_META_FMT_UVC pixel format for all of them. Users have to
> parse data, based on the specific camera model information.
> 
> Signed-off-by: Guennadi Liakhovetski 
> ---
> 
> v3: all comments to v2 have been addressed - thanks! Most important 
> ones:
> 
> * metadata nodes are now only created for cameras, for which a 
>   UVC_QUIRK_METADATA_NODE flag is specified
> * no metadata nodes are created for video interfaces with isochronous 
>   endpoints. For those to be meaningfully supported a UVC standard 
>   extension is required.
> * the uvc_queue.c vb2_queue implementation is extended and used 
>   instead of a separate implementation
> 
>  drivers/media/usb/uvc/Makefile   |   2 +-
>  drivers/media/usb/uvc/uvc_driver.c   |   4 +
>  drivers/media/usb/uvc/uvc_isight.c   |   2 +-
>  drivers/media/usb/uvc/uvc_metadata.c | 159 
> +++
>  drivers/media/usb/uvc/uvc_queue.c|  68 ++-
>  drivers/media/usb/uvc/uvc_video.c|  41 -
>  drivers/media/usb/uvc/uvcvideo.h |  19 -
>  drivers/media/v4l2-core/v4l2-ioctl.c |   1 +
>  include/uapi/linux/uvcvideo.h|   7 ++
>  include/uapi/linux/videodev2.h   |   3 +
>  10 files changed, 278 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/media/usb/uvc/uvc_metadata.c
> 
> diff --git a/drivers/media/usb/uvc/Makefile b/drivers/media/usb/uvc/Makefile
> index c26d12f..06c7cd3 100644
> --- a/drivers/media/usb/uvc/Makefile
> +++ b/drivers/media/usb/uvc/Makefile
> @@ -1,5 +1,5 @@
>  uvcvideo-objs  := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o 
> \
> -   uvc_status.o uvc_isight.o uvc_debugfs.o
> +   uvc_status.o uvc_isight.o uvc_debugfs.o uvc_metadata.o
>  ifeq ($(CONFIG_MEDIA_CONTROLLER),y)
>  uvcvideo-objs  += uvc_entity.o
>  endif
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index 04bf350..b2e9eef 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1865,6 +1865,7 @@ static void uvc_unregister_video(struct uvc_device *dev)
>   continue;
>  
>   video_unregister_device(>vdev);
> + video_unregister_device(>meta.vdev);
>  
>   uvc_debugfs_cleanup_stream(stream);
>   }
> @@ -1926,6 +1927,9 @@ static int uvc_register_video(struct uvc_device *dev,
>   return ret;
>   }
>  
> + /* Register a metadata node. */
> + uvc_meta_register(stream);
> +
>   if (stream->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
>   stream->chain->caps |= V4L2_CAP_VIDEO_CAPTURE;
>   else
> diff --git a/drivers/media/usb/uvc/uvc_isight.c 
> b/drivers/media/usb/uvc/uvc_isight.c
> index 8510e725..fb940cf 100644
> --- a/drivers/media/usb/uvc/uvc_isight.c
> +++ b/drivers/media/usb/uvc/uvc_isight.c
> @@ -100,7 +100,7 @@ static int isight_decode(struct uvc_video_queue *queue, 
> struct uvc_buffer *buf,
>  }
>  
>  void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
> - struct uvc_buffer *buf)
> + struct uvc_buffer *buf, struct uvc_buffer *meta_buf)
>  {
>   int ret, i;
>  
> diff --git 

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[kbuild test robot]

Hi Guennadi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.9 next-20161209]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Guennadi-Liakhovetski/uvcvideo-metadata-device-node/20161213-004101
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)


vim +/case +81 drivers/media/usb/uvc/uvc_queue.c

65  }
66  }
67  
68  /* 
-
69   * videobuf2 queue operations
70   */
71  
72  int uvc_queue_setup(struct vb2_queue *vq,
73  unsigned int *nbuffers, unsigned int *nplanes,
74  unsigned int sizes[], struct device *alloc_devs[])
75  {
76  struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
77  struct uvc_streaming *stream;
78  unsigned int size;
79  
80  switch (vq->type) {
  > 81  case V4L2_BUF_TYPE_META_CAPTURE:
82  size = UVC_PAYLOAD_HEADER_MAX_SIZE;
83  
84  if (*nplanes && *nplanes != 1)
85  return -EINVAL;
86  
87  break;
88  default:
89  stream = uvc_queue_to_stream(queue);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[kbuild test robot]

Hi Guennadi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9 next-20161209]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Guennadi-Liakhovetski/uvcvideo-metadata-device-node/20161213-004101
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-i0-12120350 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/media/usb/uvc/uvc_metadata.c: In function 'meta_v4l2_get_format':
   drivers/media/usb/uvc/uvc_metadata.c:59:45: error: 'union ' has 
no member named 'meta'
 struct v4l2_meta_format *fmt = >fmt.meta;
^
>> drivers/media/usb/uvc/uvc_metadata.c:64:24: error: dereferencing pointer to 
>> incomplete type
 memset(fmt, 0, sizeof(*fmt));
   ^
   drivers/media/usb/uvc/uvc_metadata.c:66:5: error: dereferencing pointer to 
incomplete type
 fmt->dataformat = V4L2_META_FMT_UVC;
^
   drivers/media/usb/uvc/uvc_metadata.c:67:5: error: dereferencing pointer to 
incomplete type
 fmt->buffersize = UVC_PAYLOAD_HEADER_MAX_SIZE;
^
   drivers/media/usb/uvc/uvc_metadata.c: At top level:
   drivers/media/usb/uvc/uvc_metadata.c:74:2: error: unknown field 
'vidioc_g_fmt_meta_cap' specified in initializer
 .vidioc_g_fmt_meta_cap  = meta_v4l2_get_format,
 ^
>> drivers/media/usb/uvc/uvc_metadata.c:74:2: warning: initialization from 
>> incompatible pointer type
   drivers/media/usb/uvc/uvc_metadata.c:74:2: warning: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_cap')
   drivers/media/usb/uvc/uvc_metadata.c:75:2: error: unknown field 
'vidioc_s_fmt_meta_cap' specified in initializer
 .vidioc_s_fmt_meta_cap  = meta_v4l2_get_format,
 ^
   drivers/media/usb/uvc/uvc_metadata.c:75:2: warning: initialization from 
incompatible pointer type
   drivers/media/usb/uvc/uvc_metadata.c:75:2: warning: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_overlay')
   drivers/media/usb/uvc/uvc_metadata.c:76:2: error: unknown field 
'vidioc_try_fmt_meta_cap' specified in initializer
 .vidioc_try_fmt_meta_cap = meta_v4l2_get_format,
 ^
   drivers/media/usb/uvc/uvc_metadata.c:76:2: warning: initialization from 
incompatible pointer type
   drivers/media/usb/uvc/uvc_metadata.c:76:2: warning: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_out')
   drivers/media/usb/uvc/uvc_metadata.c: In function 'uvc_meta_register':
   drivers/media/usb/uvc/uvc_metadata.c:135:22: error: 'V4L2_CAP_META_CAPTURE' 
undeclared (first use in this function)
 vdev->device_caps = V4L2_CAP_META_CAPTURE | V4L2_CAP_STREAMING;
 ^
   drivers/media/usb/uvc/uvc_metadata.c:135:22: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/media/usb/uvc/uvc_metadata.c:141:16: error: 
'V4L2_BUF_TYPE_META_CAPTURE' undeclared (first use in this function)
 queue->type = V4L2_BUF_TYPE_META_CAPTURE;
   ^

vim +64 drivers/media/usb/uvc/uvc_metadata.c

53  }
54  
55  static int meta_v4l2_get_format(struct file *file, void *fh,
56  struct v4l2_format *format)
57  {
58  struct v4l2_fh *vfh = file->private_data;
  > 59  struct v4l2_meta_format *fmt = >fmt.meta;
60  
61  if (format->type != vfh->vdev->queue->type)
62  return -EINVAL;
63  
  > 64  memset(fmt, 0, sizeof(*fmt));
65  
66  fmt->dataformat = V4L2_META_FMT_UVC;
  > 67  fmt->buffersize = UVC_PAYLOAD_HEADER_MAX_SIZE;
68  
69  return 0;
70  }
71  
72  static const struct v4l2_ioctl_ops uvc_meta_ioctl_ops = {
73  .vidioc_querycap= meta_v4l2_querycap,
  > 74  .vidioc_g_fmt_meta_cap  = meta_v4l2_get_format,
75  .vidioc_s_fmt_meta_cap  = meta_v4l2_get_format,
76  .vidioc_try_fmt_meta_cap= meta_v4l2_get_format,
77  .vidioc_reqbufs = vb2_ioctl_reqbufs,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3 4/4] uvcvideo: add a metadata device node

[kbuild test robot]

Hi Guennadi,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9 next-20161209]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Guennadi-Liakhovetski/uvcvideo-metadata-device-node/20161213-004101
base:   git://linuxtv.org/media_tree.git master
config: i386-randconfig-a0-12120946 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/usb/uvc/uvc_queue.c: In function 'uvc_queue_setup':
>> drivers/media/usb/uvc/uvc_queue.c:81:7: error: 'V4L2_BUF_TYPE_META_CAPTURE' 
>> undeclared (first use in this function)
 case V4L2_BUF_TYPE_META_CAPTURE:
  ^~
   drivers/media/usb/uvc/uvc_queue.c:81:7: note: each undeclared identifier is 
reported only once for each function it appears in
   drivers/media/usb/uvc/uvc_queue.c: In function 'uvc_buffer_prepare':
   drivers/media/usb/uvc/uvc_queue.c:121:7: error: 'V4L2_BUF_TYPE_META_CAPTURE' 
undeclared (first use in this function)
 case V4L2_BUF_TYPE_META_CAPTURE:
  ^~
   drivers/media/usb/uvc/uvc_queue.c: In function 'uvc_stop_streaming':
   drivers/media/usb/uvc/uvc_queue.c:198:18: error: 
'V4L2_BUF_TYPE_META_CAPTURE' undeclared (first use in this function)
 if (vq->type != V4L2_BUF_TYPE_META_CAPTURE) {
 ^~
--
   drivers/media/usb/uvc/uvc_metadata.c: In function 'meta_v4l2_get_format':
>> drivers/media/usb/uvc/uvc_metadata.c:59:45: error: 'union ' has 
>> no member named 'meta'
 struct v4l2_meta_format *fmt = >fmt.meta;
^
   In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/thread_info.h:11,
from include/linux/thread_info.h:58,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/media/usb/uvc/uvc_metadata.c:15:
>> drivers/media/usb/uvc/uvc_metadata.c:64:24: error: dereferencing pointer to 
>> incomplete type 'struct v4l2_meta_format'
 memset(fmt, 0, sizeof(*fmt));
   ^~
   arch/x86/include/asm/string_32.h:325:52: note: in definition of macro 
'memset'
#define memset(s, c, count) __builtin_memset(s, c, count)
   ^
   drivers/media/usb/uvc/uvc_metadata.c: At top level:
>> drivers/media/usb/uvc/uvc_metadata.c:74:2: error: unknown field 
>> 'vidioc_g_fmt_meta_cap' specified in initializer
 .vidioc_g_fmt_meta_cap  = meta_v4l2_get_format,
 ^
>> drivers/media/usb/uvc/uvc_metadata.c:74:28: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 .vidioc_g_fmt_meta_cap  = meta_v4l2_get_format,
   ^~~~
   drivers/media/usb/uvc/uvc_metadata.c:74:28: note: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_cap')
>> drivers/media/usb/uvc/uvc_metadata.c:75:2: error: unknown field 
>> 'vidioc_s_fmt_meta_cap' specified in initializer
 .vidioc_s_fmt_meta_cap  = meta_v4l2_get_format,
 ^
   drivers/media/usb/uvc/uvc_metadata.c:75:28: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .vidioc_s_fmt_meta_cap  = meta_v4l2_get_format,
   ^~~~
   drivers/media/usb/uvc/uvc_metadata.c:75:28: note: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_overlay')
>> drivers/media/usb/uvc/uvc_metadata.c:76:2: error: unknown field 
>> 'vidioc_try_fmt_meta_cap' specified in initializer
 .vidioc_try_fmt_meta_cap = meta_v4l2_get_format,
 ^
   drivers/media/usb/uvc/uvc_metadata.c:76:29: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .vidioc_try_fmt_meta_cap = meta_v4l2_get_format,
^~~~
   drivers/media/usb/uvc/uvc_metadata.c:76:29: note: (near initialization for 
'uvc_meta_ioctl_ops.vidioc_enum_fmt_vid_out')
   drivers/media/usb/uvc/uvc_metadata.c: In function 'uvc_meta_register':
>> drivers/media/usb/uvc/uvc_metadata.c:135:22: error: 'V4L2_CAP_META_CAPTURE' 
>> undeclared (first use in this function)
 vdev->device_caps = V4L2_CAP_META_CAPTURE |