linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: "Moritz Dötterl" <moritz.doetterl@pentlandfirth.com>,
	"linux-uvc-devel@lists.berlios.de"
	<linux-uvc-devel@lists.berlios.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [linux-uvc-devel] metadata device file
Date: Fri, 15 Feb 2019 20:51:08 +0000	[thread overview]
Message-ID: <d7b02766-b920-8cf7-9db8-275dfc22851c@ideasonboard.com> (raw)
In-Reply-To: <d6a7d5e54acd4cb6b71eacf0724a92e4AM0PR10MB2788C3DEE0DF6144DAFA6FA1F0600@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>

Hi Moritz,

On 15/02/2019 08:45, Moritz Dötterl wrote:
> Hello
> 
> Recently we updated the Kernel on our Ubuntu machines from 4.15 to 4.18
> because the OS was randomly freezing. However with the new Kernel we ran
> into a problem regarding our two webcams. We had two /dev/video device
> files per camera of which only one seemed to work.

Yes, a new device node has been added to represent the meta-data from
the device.

You should be able to enumerate the devices, and you should
verify/validate the capabilities of the device after you open it.

A UVC capture device will expose the V4L2_CAP_VIDEO_OUTPUT capability flag.

> The problem was that
> our application would just randomly open one of those two device files

Is this an application you have control over the source code for?
or some external application?

> and then crashed if it opened the wrong one. After some search i figured
> out that the second device file is for meta data (which might not be
> provided by our camera i guess...). However i also found the line in the
> uvc_driver.c which generates the device file
> (https://elixir.bootlin.com/linux/v4.18/source/drivers/media/usb/uvc/uvc_driver.c#L2005)
> that line including the whole uvc_metadata.c was added when comparing
> 4.15 and 4.18 Kernel. I took that line out, recompiled the Kernel and
> ended up with having only one /dev/video device file per camera. I also
> found it is using the exact same function to register the device node
> that the uvc_driver.c is using and also using the same vfl_devnode_type
>  (VFL_TYPE_GRABBER) and therefore ending up as a /dev/video device. Was
> that move on purpose?

Yes, this addition was on purpose. It was added by the following patch:

https://www.spinics.net/lists/linux-media/msg125681.html

I've added the linux-media mailing list on Cc where you will be able to
find better support if this topic causes further problems.


> Why was it split up in two device files, or is
> that just added functionality?

I believe it is just added functionality - not split.

> I would rather like this device file to
> have a different name because in this setup it is not easily decidable

Perhaps some different naming might have continued to hide this issue
for you but it would only have hidden a potential bug.

Even with a different name, you can not expect that all /dev/video*
nodes are capture devices. They can be output devices or M2M devices for
example. Your application should always check the device capabilities
using the V4L2 API's as applicable.


> if a /dev/video device is the "real" webcam or just the meta data... So
> i would prefer that to end up as something like /dev/metavideo or so (
> or maybe easier: change the type to VFL_TYPE_SUBDEV so it will end up as
> a v4l-subdev device, that sounds more suitable for me...)

I think in this instance it has to be a full video node and not a subdev
so that data can be captured from the device node.


> What are the plans for this in future kernel versions? Should it stay
> like it is now or are there plans to change/evolve the meta data
> handling again?

This is in mainline now - so I would expect it to continue to be supported.

> 
> 
> Thanks very much.
> 
> 
> Best regards / Mit freundlichen Grüßen
> *Moritz Dötterl*
> 
> Pentland Firth Software GmbH
> 
> Hofmannstr. 61
> 81379 München, Germany
> 
> Mobile: +49 17655389056
> 
> moritz.doetterl@pentlandfirth.com <mailto:aron.borbath@pentlandfirth.com>
> 
> ----------------------------------------------------------------------------------------------------------------------------------
> Pentland Firth is *Microsoft Gold Partner*
> 
> Brands we own:  www.whiz-cart.com <http://www.whiz-cart.com/>
> ----------------------------------------------------------------------------------------------------------------------------------
> Sitz der Gesellschaft: München, Handelsregister München, HRB 155 786,
> Geschäftsführer: Frank Heinrich
> 
> 
> 
> 
> _______________________________________________
> Linux-uvc-devel mailing list
> Linux-uvc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel
> 

-- 
Regards
--
Kieran

       reply	other threads:[~2019-02-15 20:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d6a7d5e54acd4cb6b71eacf0724a92e4AM0PR10MB2788C3DEE0DF6144DAFA6FA1F0600@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
2019-02-15 20:51 ` Kieran Bingham [this message]
     [not found]   ` <AM0PR10MB2788437E98A6CFB2780A7026F07D0@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
2019-02-20  8:12     ` [linux-uvc-devel] metadata device file 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=d7b02766-b920-8cf7-9db8-275dfc22851c@ideasonboard.com \
    --to=kieran.bingham@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-uvc-devel@lists.berlios.de \
    --cc=moritz.doetterl@pentlandfirth.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;
as well as URLs for NNTP newsgroup(s).