* Re: [linux-uvc-devel] metadata device file
[not found] <d6a7d5e54acd4cb6b71eacf0724a92e4AM0PR10MB2788C3DEE0DF6144DAFA6FA1F0600@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
@ 2019-02-15 20:51 ` Kieran Bingham
[not found] ` <AM0PR10MB2788437E98A6CFB2780A7026F07D0@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
0 siblings, 1 reply; 2+ messages in thread
From: Kieran Bingham @ 2019-02-15 20:51 UTC (permalink / raw)
To: Moritz Dötterl, linux-uvc-devel
Cc: Linux Media Mailing List, Laurent Pinchart, Guennadi Liakhovetski
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [linux-uvc-devel] metadata device file
[not found] ` <AM0PR10MB2788437E98A6CFB2780A7026F07D0@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
@ 2019-02-20 8:12 ` Guennadi Liakhovetski
0 siblings, 0 replies; 2+ messages in thread
From: Guennadi Liakhovetski @ 2019-02-20 8:12 UTC (permalink / raw)
To: Moritz Dötterl
Cc: linux-uvc-devel, kieran.bingham, Linux Media Mailing List,
Laurent Pinchart
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@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
>
>
> ________________________________
> From: Kieran Bingham <kieran.bingham@ideasonboard.com>
> Sent: Friday, February 15, 2019 9:51:08 PM
> To: Moritz Dötterl; linux-uvc-devel@lists.berlios.de
> 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@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> <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
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-02-20 8:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <d6a7d5e54acd4cb6b71eacf0724a92e4AM0PR10MB2788C3DEE0DF6144DAFA6FA1F0600@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
2019-02-15 20:51 ` [linux-uvc-devel] metadata device file Kieran Bingham
[not found] ` <AM0PR10MB2788437E98A6CFB2780A7026F07D0@AM0PR10MB2788.EURPRD10.PROD.OUTLOOK.COM>
2019-02-20 8:12 ` Guennadi Liakhovetski
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).