Bug: Two device nodes created in /dev for a single UVC webcam

Bug: Two device nodes created in /dev for a single UVC webcam

[Alexandre-Xavier Labonté-Lamoureux]

Hi,

I'm running Linux 4.9.0-5-amd64 on Debian. I built the drivers from
the latest git and installed the modules. Now, two device nodes are
created for my webcam. This is not normal as it has never happened to
me before. If I connect another webcam to my laptop, two more device
nodes will be created for this webcam. So two new device nodes are
created for a single webcam.

The name of my webcam appears twice in the device comobox in Guvcview
because of this. One of them will not work if I select it. My webcam
has completely stopped working with Cheese and VLC.

> v4l2-ctl --list-devices
Laptop_Integrated_Webcam_E4HD:  (usb-0000:00:1a.0-1.5):
    /dev/video0
    /dev/video1

> ls /dev/video*
/dev/video0  /dev/video1

Have a nice day,
Alexandre-Xavier

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Kieran Bingham]

Hi Alexandre,

Thankyou for your bug report,

On 17/02/18 20:47, Alexandre-Xavier Labonté-Lamoureux wrote:
> Hi,
> 
> I'm running Linux 4.9.0-5-amd64 on Debian. I built the drivers from
> the latest git and installed the modules.

Could you please be specific here?

Are you referring to linux-media/master branch or such? The latest from Linus' tree?

Please also detail the steps you have taken to reproduce this issue - and of
course - if you have made any code changes to make the latest UVC module compile
against a v4.9 kernel...

Building the latest git tree and installing as a module on a v4.9 kernel is
quite a leap... I wouldn't have expected that to work.

The code would have to be compiled against a v4.9 kernel directly, and I didn't
think compiling the UVC driver against older kernels worked.

(at least it didn't work cleanly when I tried to compile v4.15 against a v4.14
kernel last month)

> Now, two device nodes are
> created for my webcam. This is not normal as it has never happened to
> me before. If I connect another webcam to my laptop, two more device
> nodes will be created for this webcam. So two new device nodes are
> created for a single webcam.

I believe Guennadi's latest work for handling meta-data (in the latest v4.16-rc1
I think) will create two device nodes.


> The name of my webcam appears twice in the device comobox in Guvcview
> because of this. One of them will not work if I select it.

It would be expected that only the device with video functions as a streaming
camera device, while the other would not.


> My webcam has completely stopped working with Cheese and VLC.

This part is of particular concern however.

Guennadi - Have you tested Cheese/VLC with your series?

Are there any known issues that need looking at ?

>> v4l2-ctl --list-devices
> Laptop_Integrated_Webcam_E4HD:  (usb-0000:00:1a.0-1.5):
>     /dev/video0
>     /dev/video1
> 
>> ls /dev/video*
> /dev/video0  /dev/video1
>
> Have a nice day,
> Alexandre-Xavier

Regards

Kieran Bingham

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Guennadi Liakhovetski]

Hi Kieran,

On Mon, 19 Feb 2018, Kieran Bingham wrote:

> Hi Alexandre,
> 
> Thankyou for your bug report,
> 
> On 17/02/18 20:47, Alexandre-Xavier Labonté-Lamoureux wrote:
> > Hi,
> > 
> > I'm running Linux 4.9.0-5-amd64 on Debian. I built the drivers from
> > the latest git and installed the modules.
> 
> Could you please be specific here?
> 
> Are you referring to linux-media/master branch or such? The latest from Linus' tree?
> 
> Please also detail the steps you have taken to reproduce this issue - and of
> course - if you have made any code changes to make the latest UVC module compile
> against a v4.9 kernel...
> 
> Building the latest git tree and installing as a module on a v4.9 kernel is
> quite a leap... I wouldn't have expected that to work.
> 
> The code would have to be compiled against a v4.9 kernel directly, and I didn't
> think compiling the UVC driver against older kernels worked.
> 
> (at least it didn't work cleanly when I tried to compile v4.15 against a v4.14
> kernel last month)
> 
> > Now, two device nodes are
> > created for my webcam. This is not normal as it has never happened to
> > me before. If I connect another webcam to my laptop, two more device
> > nodes will be created for this webcam. So two new device nodes are
> > created for a single webcam.
> 
> I believe Guennadi's latest work for handling meta-data (in the latest v4.16-rc1
> I think) will create two device nodes.

That's correct. The lower index node (/dev/video0) is a video node, the 
higher videoo node (/dev/video1) is a metadata node.

> > The name of my webcam appears twice in the device comobox in Guvcview
> > because of this. One of them will not work if I select it.
> 
> It would be expected that only the device with video functions as a streaming
> camera device, while the other would not.

Exactly.

> > My webcam has completely stopped working with Cheese and VLC.
> 
> This part is of particular concern however.
> 
> Guennadi - Have you tested Cheese/VLC with your series?

Sure, with cheese you can specify which camera you need by using its 
--device= parameter. Eventually it's expected, that those programs will be 
updated to recognise metadata nodes and not attempt to use them.

Thanks
Guennadi

> Are there any known issues that need looking at ?
> 
> >> v4l2-ctl --list-devices
> > Laptop_Integrated_Webcam_E4HD:  (usb-0000:00:1a.0-1.5):
> >     /dev/video0
> >     /dev/video1
> > 
> >> ls /dev/video*
> > /dev/video0  /dev/video1
> >
> > Have a nice day,
> > Alexandre-Xavier
> 
> Regards
> 
> Kieran Bingham
> 
> 

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Laurent Pinchart]

Hello,

On Monday, 19 February 2018 15:58:40 EET Guennadi Liakhovetski wrote:
> On Mon, 19 Feb 2018, Kieran Bingham wrote:
> > On 17/02/18 20:47, Alexandre-Xavier Labonté-Lamoureux wrote:
> >> Hi,
> >> 
> >> I'm running Linux 4.9.0-5-amd64 on Debian. I built the drivers from
> >> the latest git and installed the modules.
> > 
> > Could you please be specific here?
> > 
> > Are you referring to linux-media/master branch or such? The latest from
> > Linus' tree?
> > 
> > Please also detail the steps you have taken to reproduce this issue - and
> > of course - if you have made any code changes to make the latest UVC
> > module compile against a v4.9 kernel...
> > 
> > Building the latest git tree and installing as a module on a v4.9 kernel
> > is quite a leap... I wouldn't have expected that to work.
> > 
> > The code would have to be compiled against a v4.9 kernel directly, and I
> > didn't think compiling the UVC driver against older kernels worked.
> > 
> > (at least it didn't work cleanly when I tried to compile v4.15 against a
> > v4.14 kernel last month)
> > 
> >> Now, two device nodes are created for my webcam. This is not normal as
> >> it has never happened to me before. If I connect another webcam to my
> >> laptop, two more device nodes will be created for this webcam. So two
> >> new device nodes are created for a single webcam.
> > 
> > I believe Guennadi's latest work for handling meta-data (in the latest
> > v4.16-rc1 I think) will create two device nodes.
> 
> That's correct. The lower index node (/dev/video0) is a video node, the
> higher videoo node (/dev/video1) is a metadata node.
> 
> > > The name of my webcam appears twice in the device comobox in Guvcview
> > > because of this. One of them will not work if I select it.
> > 
> > It would be expected that only the device with video functions as a
> > streaming camera device, while the other would not.
> 
> Exactly.
> 
> > > My webcam has completely stopped working with Cheese and VLC.
> > 
> > This part is of particular concern however.
> > 
> > Guennadi - Have you tested Cheese/VLC with your series?
> 
> Sure, with cheese you can specify which camera you need by using its
> --device= parameter. Eventually it's expected, that those programs will be
> updated to recognise metadata nodes and not attempt to use them.

I've tested VLC (2.2.8) and haven't noticed any issue. If a program is 
directed to the metadata video node and tries to capture video from it it will 
obviously fail. That being said, software that work today should continue 
working, otherwise it's a regression, and we'll have to handle that.

> > Are there any known issues that need looking at ?
> > 
> >>> v4l2-ctl --list-devices
> >> 
> >> Laptop_Integrated_Webcam_E4HD:  (usb-0000:00:1a.0-1.5):
> >>     /dev/video0
> >>     /dev/video1
> >>> 
> >>> ls /dev/video*
> >> 
> >> /dev/video0  /dev/video1

-- 
Regards,

Laurent Pinchart

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Devin Heitmueller]

Hi Laurent,

On Mon, Feb 19, 2018 at 11:19 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> I've tested VLC (2.2.8) and haven't noticed any issue. If a program is
> directed to the metadata video node and tries to capture video from it it will
> obviously fail. That being said, software that work today should continue
> working, otherwise it's a regression, and we'll have to handle that.

Perhaps it shouldn't be a video node then (as we do with VBI devices).
Would something like /dev/videometadataX would be more appropriate?

People have for years operated under the expectation that /dev/videoX
nodes are video nodes.  If we're going to be creating things with that
name which aren't video nodes then that is going to cause considerable
confusion as well as messing up all sorts of existing applications
which operate under that expectation.

I know that some of the older PCI boards have always exposed a bunch
of video nodes for various things (i.e. raw video vs. mpeg, etc), but
because USB devices have traditionally been simpler they generally
expose only one node of each type (i.e. one /dev/videoX, /dev/vbiX
/dev/radioX).  I've already gotten an email from a customer who has a
ton of scripts which depend on this behavior, so please seriously
consider the implications of this design decision.

It's easy to brush this off as "all the existing applications will
eventually be updated", but you're talking about changing the basic
behavior of how these device nodes have been presented for over a
decade.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Laurent Pinchart]

Hi Devin,

On Tuesday, 20 February 2018 20:18:16 EET Devin Heitmueller wrote:
> On Mon, Feb 19, 2018 at 11:19 AM, Laurent Pinchart wrote:
> > I've tested VLC (2.2.8) and haven't noticed any issue. If a program is
> > directed to the metadata video node and tries to capture video from it it
> > will obviously fail. That being said, software that work today should
> > continue working, otherwise it's a regression, and we'll have to handle
> > that.
> 
> Perhaps it shouldn't be a video node then (as we do with VBI devices).
> Would something like /dev/videometadataX would be more appropriate?

We've thought about it, and the initial implementation created a metadata 
device node instead of a video device node. This has been rejected, see 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg97454.html and 
https://www.mail-archive.com/linux-media@vger.kernel.org/msg97446.html.

> People have for years operated under the expectation that /dev/videoX
> nodes are video nodes.  If we're going to be creating things with that
> name which aren't video nodes then that is going to cause considerable
> confusion as well as messing up all sorts of existing applications
> which operate under that expectation.
> 
> I know that some of the older PCI boards have always exposed a bunch
> of video nodes for various things (i.e. raw video vs. mpeg, etc), but
> because USB devices have traditionally been simpler they generally
> expose only one node of each type (i.e. one /dev/videoX, /dev/vbiX
> /dev/radioX).  I've already gotten an email from a customer who has a
> ton of scripts which depend on this behavior, so please seriously
> consider the implications of this design decision.

While I can't speak about other USB devices as I'm not too familiar with them, 
please note that the UVC driver already exposes multiple video nodes related 
to video capture (or video output) for some devices, and will posssibly do so 
increasingly in the future when we add support for UVC 1.5. We can reconsider 
the decision of exposing metadata through a video node, but adding new video 
nodes to expose additional compressed video streams for UVC 1.5 support is 
something that userspace has to live with the same way it already has to live 
with multiple video nodes for older PCI boards.

> It's easy to brush this off as "all the existing applications will
> eventually be updated", but you're talking about changing the basic
> behavior of how these device nodes have been presented for over a
> decade.

That's not what I meant, I might have not expressed myself correctly. Updating 
applications is something we should strive for when we want to get rid of an 
undesired userspace behaviour, but that's in no way an excuse for breaking 
anything. Regarding the issue reported by Alexandre-Xavier, it looks to me 
like he might be suffering from another problem, possibly part of the same 
patch series, but not caused by the extra video device node. That's why I 
asked for more information before taking any decision.

-- 
Regards,

Laurent Pinchart

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Alexandre-Xavier Labonté-Lamoureux]

Hi Kieran,

This is how I built the drivers:

$ git clone --depth=1 git://linuxtv.org/media_build.git
$ cd media_build
$ ./build --main-git

I then installed the newly built kernel modules:

$ sudo make install

Once the modules were updated, I restarted my computer to make sure
every module got reloaded. I didn't make any changes to the code and I
found the issues after trying each of those programs individually
after I restarted my computer.

This was the latest commit when I cloned the repo:

commit d144cfe4b3c37ece55ae27778c99765d4943c4fa
Author: Jasmin Jessich <jasmin@anw.at>
Date:   Fri Feb 16 22:40:49 2018 +0100
    Re-generated v3.12_kfifo_in.patch

My version of VLC is 2.2.6. Here's a copy of the relevant data of
VLC's log file in case it can help: https://paste.debian.net/1011025/
In this case, I tried to open /dev/video0 first and /dev/video1 second.

I can also try with ffplay:
$ ffplay /dev/video0

I get this: [video4linux2,v4l2 @ 0x7f2160000920]
ioctl(VIDIOC_STREAMON): Message too long
/dev/video0: Message too long

A new message appears in dmesg: uvcvideo: Failed to submit URB 0 (-90).

$ ffplay /dev/video1

I get this:
[video4linux2,v4l2 @ 0x7f00ec000920] ioctl(VIDIOC_G_INPUT):
Inappropriate ioctl for device
/dev/video1: Inappropriate ioctl for device

Like Guennadi said, /dev/video1 is a metadata node, so I don't expect
it to work. In the case of /dev/video0, I can't tell what could be
wrong from the error message.

Alexandre-Xavier

On Mon, Feb 19, 2018 at 8:52 AM, Kieran Bingham
<kieran.bingham@ideasonboard.com> wrote:
> Hi Alexandre,
>
> Thankyou for your bug report,
>
> On 17/02/18 20:47, Alexandre-Xavier Labonté-Lamoureux wrote:
>> Hi,
>>
>> I'm running Linux 4.9.0-5-amd64 on Debian. I built the drivers from
>> the latest git and installed the modules.
>
> Could you please be specific here?
>
> Are you referring to linux-media/master branch or such? The latest from Linus' tree?
>
> Please also detail the steps you have taken to reproduce this issue - and of
> course - if you have made any code changes to make the latest UVC module compile
> against a v4.9 kernel...
>
> Building the latest git tree and installing as a module on a v4.9 kernel is
> quite a leap... I wouldn't have expected that to work.
>
> The code would have to be compiled against a v4.9 kernel directly, and I didn't
> think compiling the UVC driver against older kernels worked.
>
> (at least it didn't work cleanly when I tried to compile v4.15 against a v4.14
> kernel last month)
>
>> Now, two device nodes are
>> created for my webcam. This is not normal as it has never happened to
>> me before. If I connect another webcam to my laptop, two more device
>> nodes will be created for this webcam. So two new device nodes are
>> created for a single webcam.
>
> I believe Guennadi's latest work for handling meta-data (in the latest v4.16-rc1
> I think) will create two device nodes.
>
>
>> The name of my webcam appears twice in the device comobox in Guvcview
>> because of this. One of them will not work if I select it.
>
> It would be expected that only the device with video functions as a streaming
> camera device, while the other would not.
>
>
>> My webcam has completely stopped working with Cheese and VLC.
>
> This part is of particular concern however.
>
> Guennadi - Have you tested Cheese/VLC with your series?
>
> Are there any known issues that need looking at ?
>
>>> v4l2-ctl --list-devices
>> Laptop_Integrated_Webcam_E4HD:  (usb-0000:00:1a.0-1.5):
>>     /dev/video0
>>     /dev/video1
>>
>>> ls /dev/video*
>> /dev/video0  /dev/video1
>>
>> Have a nice day,
>> Alexandre-Xavier
>
> Regards
>
> Kieran Bingham
>
>

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Laurent Pinchart]

Hi Alexandre-Xavier,

On Monday, 19 February 2018 19:29:24 EET Alexandre-Xavier Labonté-Lamoureux 
wrote:
> Hi Kieran,
> 
> This is how I built the drivers:
> 
> $ git clone --depth=1 git://linuxtv.org/media_build.git
> $ cd media_build
> $ ./build --main-git
> 
> I then installed the newly built kernel modules:
> 
> $ sudo make install
> 
> Once the modules were updated, I restarted my computer to make sure
> every module got reloaded. I didn't make any changes to the code and I
> found the issues after trying each of those programs individually
> after I restarted my computer.
> 
> This was the latest commit when I cloned the repo:
> 
> commit d144cfe4b3c37ece55ae27778c99765d4943c4fa
> Author: Jasmin Jessich <jasmin@anw.at>
> Date:   Fri Feb 16 22:40:49 2018 +0100
>     Re-generated v3.12_kfifo_in.patch
> 
> My version of VLC is 2.2.6. Here's a copy of the relevant data of
> VLC's log file in case it can help: https://paste.debian.net/1011025/
> In this case, I tried to open /dev/video0 first and /dev/video1 second.
> 
> I can also try with ffplay:
> $ ffplay /dev/video0
> 
> I get this: [video4linux2,v4l2 @ 0x7f2160000920]
> ioctl(VIDIOC_STREAMON): Message too long
> /dev/video0: Message too long
> 
> A new message appears in dmesg: uvcvideo: Failed to submit URB 0 (-90).

That's interesting, and possibly unrelated to the patch series that added 
metadata capture support. Would you be able to revert that patch series and 
see if the problem still occurs ? The four commits to be reverted are

088ead25524583e2200aa99111bea2f66a86545a
3bc85817d7982ed53fbc9b150b0205beff68ca5c
94c53e26dc74744cc4f9a8ddc593b7aef96ba764
31a96f4c872e8fb953c853630f69d5de6ec961c9

And if you could bisect the issue it would be even better :-)

Could you also send me the output of lsusb -v for your camera (you can 
restrict it to the camera with -d VID:PID), running as root if possible ?

> $ ffplay /dev/video1
> 
> I get this:
> [video4linux2,v4l2 @ 0x7f00ec000920] ioctl(VIDIOC_G_INPUT):
> Inappropriate ioctl for device
> /dev/video1: Inappropriate ioctl for device
> 
> Like Guennadi said, /dev/video1 is a metadata node, so I don't expect
> it to work. In the case of /dev/video0, I can't tell what could be
> wrong from the error message.

-- 
Regards,

Laurent Pinchart

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Alexandre-Xavier Labonté-Lamoureux]

Hi Laurent,

Sorry for the late reply.

I've been trying to reproduce the issue again. I cloned the entire
media repository later during the week and I haven't been able to
reproduce the issue after I installed the modules. A metadata node is
no longer created for my webcam. The four commits that you've
mentioned are still in the commit log, so it seems that they didn't
break anything.

I'm not sure what could have changed that would have caused it to work
fine this time. I believe that I'm in the correct branch.

$ git status
On branch media_tree/master
Your branch is up-to-date with 'r_media_tree/master'.

I probably did `./build` instead of `./build --main-git` the first time.

Thank you,
Alexandre-Xavier

On Mon, Feb 19, 2018 at 2:10 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Alexandre-Xavier,
>
> On Monday, 19 February 2018 19:29:24 EET Alexandre-Xavier Labonté-Lamoureux
> wrote:
>> Hi Kieran,
>>
>> This is how I built the drivers:
>>
>> $ git clone --depth=1 git://linuxtv.org/media_build.git
>> $ cd media_build
>> $ ./build --main-git
>>
>> I then installed the newly built kernel modules:
>>
>> $ sudo make install
>>
>> Once the modules were updated, I restarted my computer to make sure
>> every module got reloaded. I didn't make any changes to the code and I
>> found the issues after trying each of those programs individually
>> after I restarted my computer.
>>
>> This was the latest commit when I cloned the repo:
>>
>> commit d144cfe4b3c37ece55ae27778c99765d4943c4fa
>> Author: Jasmin Jessich <jasmin@anw.at>
>> Date:   Fri Feb 16 22:40:49 2018 +0100
>>     Re-generated v3.12_kfifo_in.patch
>>
>> My version of VLC is 2.2.6. Here's a copy of the relevant data of
>> VLC's log file in case it can help: https://paste.debian.net/1011025/
>> In this case, I tried to open /dev/video0 first and /dev/video1 second.
>>
>> I can also try with ffplay:
>> $ ffplay /dev/video0
>>
>> I get this: [video4linux2,v4l2 @ 0x7f2160000920]
>> ioctl(VIDIOC_STREAMON): Message too long
>> /dev/video0: Message too long
>>
>> A new message appears in dmesg: uvcvideo: Failed to submit URB 0 (-90).
>
> That's interesting, and possibly unrelated to the patch series that added
> metadata capture support. Would you be able to revert that patch series and
> see if the problem still occurs ? The four commits to be reverted are
>
> 088ead25524583e2200aa99111bea2f66a86545a
> 3bc85817d7982ed53fbc9b150b0205beff68ca5c
> 94c53e26dc74744cc4f9a8ddc593b7aef96ba764
> 31a96f4c872e8fb953c853630f69d5de6ec961c9
>
> And if you could bisect the issue it would be even better :-)
>
> Could you also send me the output of lsusb -v for your camera (you can
> restrict it to the camera with -d VID:PID), running as root if possible ?
>
>> $ ffplay /dev/video1
>>
>> I get this:
>> [video4linux2,v4l2 @ 0x7f00ec000920] ioctl(VIDIOC_G_INPUT):
>> Inappropriate ioctl for device
>> /dev/video1: Inappropriate ioctl for device
>>
>> Like Guennadi said, /dev/video1 is a metadata node, so I don't expect
>> it to work. In the case of /dev/video0, I can't tell what could be
>> wrong from the error message.
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Laurent Pinchart]

Hi Alexandre-Xavier,

On Sunday, 25 February 2018 10:19:51 EET Alexandre-Xavier Labonté-Lamoureux 
wrote:
> Hi Laurent,
> 
> Sorry for the late reply.
> 
> I've been trying to reproduce the issue again. I cloned the entire
> media repository later during the week and I haven't been able to
> reproduce the issue after I installed the modules. A metadata node is
> no longer created for my webcam. The four commits that you've
> mentioned are still in the commit log, so it seems that they didn't
> break anything.

Now that's weird. I would expect a metadata video node to be created if the 
patches I mentioned are applied. Are you sure you have loaded the modules 
corresponding to the compiled sources ?

> I'm not sure what could have changed that would have caused it to work
> fine this time. I believe that I'm in the correct branch.
> 
> $ git status
> On branch media_tree/master
> Your branch is up-to-date with 'r_media_tree/master'.
> 
> I probably did `./build` instead of `./build --main-git` the first time.
> 
> On Mon, Feb 19, 2018 at 2:10 PM, Laurent Pinchart wrote:
> > On Monday, 19 February 2018 19:29:24 EET Alexandre-Xavier
> > Labonté-Lamoureux wrote:
> >> Hi Kieran,
> >> 
> >> This is how I built the drivers:
> >> 
> >> $ git clone --depth=1 git://linuxtv.org/media_build.git
> >> $ cd media_build
> >> $ ./build --main-git
> >> 
> >> I then installed the newly built kernel modules:
> >> 
> >> $ sudo make install
> >> 
> >> Once the modules were updated, I restarted my computer to make sure
> >> every module got reloaded. I didn't make any changes to the code and I
> >> found the issues after trying each of those programs individually
> >> after I restarted my computer.
> >> 
> >> This was the latest commit when I cloned the repo:
> >> 
> >> commit d144cfe4b3c37ece55ae27778c99765d4943c4fa
> >> Author: Jasmin Jessich <jasmin@anw.at>
> >> Date:   Fri Feb 16 22:40:49 2018 +0100
> >> 
> >>     Re-generated v3.12_kfifo_in.patch
> >> 
> >> My version of VLC is 2.2.6. Here's a copy of the relevant data of
> >> VLC's log file in case it can help: https://paste.debian.net/1011025/
> >> In this case, I tried to open /dev/video0 first and /dev/video1 second.
> >> 
> >> I can also try with ffplay:
> >> $ ffplay /dev/video0
> >> 
> >> I get this: [video4linux2,v4l2 @ 0x7f2160000920]
> >> ioctl(VIDIOC_STREAMON): Message too long
> >> /dev/video0: Message too long
> >> 
> >> A new message appears in dmesg: uvcvideo: Failed to submit URB 0 (-90).
> > 
> > That's interesting, and possibly unrelated to the patch series that added
> > metadata capture support. Would you be able to revert that patch series
> > and see if the problem still occurs ? The four commits to be reverted are
> > 
> > 088ead25524583e2200aa99111bea2f66a86545a
> > 3bc85817d7982ed53fbc9b150b0205beff68ca5c
> > 94c53e26dc74744cc4f9a8ddc593b7aef96ba764
> > 31a96f4c872e8fb953c853630f69d5de6ec961c9
> > 
> > And if you could bisect the issue it would be even better :-)
> > 
> > Could you also send me the output of lsusb -v for your camera (you can
> > restrict it to the camera with -d VID:PID), running as root if possible ?
> > 
> >> $ ffplay /dev/video1
> >> 
> >> I get this:
> >> [video4linux2,v4l2 @ 0x7f00ec000920] ioctl(VIDIOC_G_INPUT):
> >> Inappropriate ioctl for device
> >> /dev/video1: Inappropriate ioctl for device
> >> 
> >> Like Guennadi said, /dev/video1 is a metadata node, so I don't expect
> >> it to work. In the case of /dev/video0, I can't tell what could be
> >> wrong from the error message.

-- 
Regards,

Laurent Pinchart

Re: Bug: Two device nodes created in /dev for a single UVC webcam

[Alexandre-Xavier Labonté-Lamoureux]

Hi Laurent,

I see why. `make install` installed my newly built modules into
`/lib/modules/4.9.0-5-amd64`, but I was running version 4.9.0-6 of the
kernel. Each kernel version has its own folder with its own modules.

I tried to revert the four commits, but they created conflicts. I
wasn't able to resolve them easily and, to be honest, I don't have a
lot of time to spend on this.

Regards,
Alexandre-Xavier

On Sun, Feb 25, 2018 at 6:41 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Alexandre-Xavier,
>
> On Sunday, 25 February 2018 10:19:51 EET Alexandre-Xavier Labonté-Lamoureux
> wrote:
>> Hi Laurent,
>>
>> Sorry for the late reply.
>>
>> I've been trying to reproduce the issue again. I cloned the entire
>> media repository later during the week and I haven't been able to
>> reproduce the issue after I installed the modules. A metadata node is
>> no longer created for my webcam. The four commits that you've
>> mentioned are still in the commit log, so it seems that they didn't
>> break anything.
>
> Now that's weird. I would expect a metadata video node to be created if the
> patches I mentioned are applied. Are you sure you have loaded the modules
> corresponding to the compiled sources ?
>
>> I'm not sure what could have changed that would have caused it to work
>> fine this time. I believe that I'm in the correct branch.
>>
>> $ git status
>> On branch media_tree/master
>> Your branch is up-to-date with 'r_media_tree/master'.
>>
>> I probably did `./build` instead of `./build --main-git` the first time.
>>
>> On Mon, Feb 19, 2018 at 2:10 PM, Laurent Pinchart wrote:
>> > On Monday, 19 February 2018 19:29:24 EET Alexandre-Xavier
>> > Labonté-Lamoureux wrote:
>> >> Hi Kieran,
>> >>
>> >> This is how I built the drivers:
>> >>
>> >> $ git clone --depth=1 git://linuxtv.org/media_build.git
>> >> $ cd media_build
>> >> $ ./build --main-git
>> >>
>> >> I then installed the newly built kernel modules:
>> >>
>> >> $ sudo make install
>> >>
>> >> Once the modules were updated, I restarted my computer to make sure
>> >> every module got reloaded. I didn't make any changes to the code and I
>> >> found the issues after trying each of those programs individually
>> >> after I restarted my computer.
>> >>
>> >> This was the latest commit when I cloned the repo:
>> >>
>> >> commit d144cfe4b3c37ece55ae27778c99765d4943c4fa
>> >> Author: Jasmin Jessich <jasmin@anw.at>
>> >> Date:   Fri Feb 16 22:40:49 2018 +0100
>> >>
>> >>     Re-generated v3.12_kfifo_in.patch
>> >>
>> >> My version of VLC is 2.2.6. Here's a copy of the relevant data of
>> >> VLC's log file in case it can help: https://paste.debian.net/1011025/
>> >> In this case, I tried to open /dev/video0 first and /dev/video1 second.
>> >>
>> >> I can also try with ffplay:
>> >> $ ffplay /dev/video0
>> >>
>> >> I get this: [video4linux2,v4l2 @ 0x7f2160000920]
>> >> ioctl(VIDIOC_STREAMON): Message too long
>> >> /dev/video0: Message too long
>> >>
>> >> A new message appears in dmesg: uvcvideo: Failed to submit URB 0 (-90).
>> >
>> > That's interesting, and possibly unrelated to the patch series that added
>> > metadata capture support. Would you be able to revert that patch series
>> > and see if the problem still occurs ? The four commits to be reverted are
>> >
>> > 088ead25524583e2200aa99111bea2f66a86545a
>> > 3bc85817d7982ed53fbc9b150b0205beff68ca5c
>> > 94c53e26dc74744cc4f9a8ddc593b7aef96ba764
>> > 31a96f4c872e8fb953c853630f69d5de6ec961c9
>> >
>> > And if you could bisect the issue it would be even better :-)
>> >
>> > Could you also send me the output of lsusb -v for your camera (you can
>> > restrict it to the camera with -d VID:PID), running as root if possible ?
>> >
>> >> $ ffplay /dev/video1
>> >>
>> >> I get this:
>> >> [video4linux2,v4l2 @ 0x7f00ec000920] ioctl(VIDIOC_G_INPUT):
>> >> Inappropriate ioctl for device
>> >> /dev/video1: Inappropriate ioctl for device
>> >>
>> >> Like Guennadi said, /dev/video1 is a metadata node, so I don't expect
>> >> it to work. In the case of /dev/video0, I can't tell what could be
>> >> wrong from the error message.
>
> --
> Regards,
>
> Laurent Pinchart
>