Hi Moritz, On Wed, 20 Feb 2019, Moritz Dötterl wrote: > Hi Kieran > > > Thank you very much for your explanation. > > At least in the setup we are using every /dev/video device is a capture device. > > Wouldn't it be good to have that configurable with a module parameter? I don't think it would. It can be argued whether the decision to add video metadata device nodes as /dev/video* was the best choice possible, but once the choice has been made, I think our best option now is to convert all users to be prepared to handle them. Thanks Guennadi > Best regards / Mit freundlichen Grüßen > Moritz Dötterl > > Pentland Firth Software GmbH > > Hofmannstr. 61 > 81379 München, Germany > > Mobile: +49 17655389056 > > moritz.doetterl@xxxxxxxxxxxxxxxxx<mailto:aron.borbath@xxxxxxxxxxxxxxxxx> > > ---------------------------------------------------------------------------------------------------------------------------------- > 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 > > > ________________________________ > From: Kieran Bingham <kieran.bingham@xxxxxxxxxxxxxxxx> > Sent: Friday, February 15, 2019 9:51:08 PM > To: Moritz Dötterl; linux-uvc-devel@xxxxxxxxxxxxxxxx > Cc: Linux Media Mailing List; Laurent Pinchart; Guennadi Liakhovetski > Subject: Re: [linux-uvc-devel] metadata device file > > 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@xxxxxxxxxxxxxxxxx <mailto:aron.borbath@xxxxxxxxxxxxxxxxx> > > > > ---------------------------------------------------------------------------------------------------------------------------------- > > Pentland Firth is *Microsoft Gold Partner* > > > > Brands we own: www.whiz-cart.com<http://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@xxxxxxxxxxxxxxxxxxxxx > > https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel > > > > -- > Regards > -- > Kieran >
