Jump to content


Photo

Static /dev/video*


  • Please log in to reply
10 replies to this topic

#1 woodtore

woodtore

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 20 March 2015 - 02:15 PM

Does anyone have any ideas on how to achieve this?

 

There is some information here: http://ubuntuforums....ad.php?t=753434

 

I tried that program but it seems that it has caused the second video device to not be initiated. lsusb shows the device but there it is not one of the /dev/video*.

 

Some specifics of my application are as follows. I am running motion on boot and have two webcams attached each having their own thread. On boot usually there will be three /dev/video* two of which are my cameras and the third I am guessing is the CSI camera which I do not have attached. The devices are assigned seemingly at random to the three /dev/video* feeds. This will cause an error 2 out of 3 times that I boot.

 

According to the link above there was a solution to this problem on the way back in 2009 dealing with /dev/v4l/ I have not been able to find this anywhere.

 

Torey


  • carpinteyrolkh likes this

#2 cwilt

cwilt

    Advanced Member

  • Members
  • PipPipPip
  • 1,012 posts

Posted 20 March 2015 - 03:40 PM

The work around in your reference was a symlink. Not sure what the cure is but will follow this thread.

#3 nunja

nunja

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts

Posted 21 March 2015 - 12:11 PM

woodtore

 

Before udev was released device nodes had to be configued using the comman mknod.

In your case the description of the video4linux devices are to be found in the kernel documentatation by searching video4linux in the file devices.txt. They belong to the character device nodes 81.

 

Since udev was widely introduced you can achieve your goal using a rule set under /etc/udev/rules.d

 

First you need to find the Vendor ID and Product ID for each USB camera in use. The easiest thing to do that is to look at your system log because such log also tells you which video device is claimed by each camera.

 

In case you have more than one camera of the same vendor and product and it's not an elcheapo USB camera you also need to look up the serial number of each camera. Without using a serial number under such circumstances udev freaks. And I think that's your problem because the second camera doesn't show.

 

You mention that you suppose that a CSI camera generates a /dev/video? but you don't have a camera of this type. Look into the modprobe files in your /etc directory and comment such camera types out by placing the # sign in front of the entry in the appropriate text file.

 

Next I give you an example for a rules file that I use in /etc/udev/rules.d that is named 50-logitec-webcam.rules. Such file handles the Logitec webcam C270 while a second one handles an elcheapo Hama CM-3010 AF webcam.

 

50-logitec-webcam.rules

 

### /etc/udev/rules.d/50-logitec-webcam.rules

### There is no rule to add /dev/dsp for usb audio devices on webcams.
### Certain programs f.e. transcode can't handle device entries in /dev/snd
### Therefore we add a /dev/dsp? for usb audio webcam devices to overcome
### such shortage.

### Older versions of udev (before systemd) use SYSFS{} instead of ATTR{}
 

### Logitech, Inc. Webcam C270
### ATTR{product}=="Logitech, Inc."
### - video4linux !!! enable only on old udev (openSUSE <= 11.4)
#SUBSYSTEM=="video4linux", BUS=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="0825", NAME="video%n"
### - microphone
#SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="0825", SYMLINK+="audio%n"
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="0825", MODE="0660", GROUP="video", SYMLINK+="audio"
### - sound dsp
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="0825", MODE="0660", GROUP="video", SYMLINK+="dsp", ENV{ID_MTP_DEVICE}="0", ENV{ID_MEDIA_PLAYER}="0", ENV{GENERATED}=1
 

In the first example ending in (NAME="video%n") udev assigns the video devices dynamic starting with /dev/video0

 

Taking such line and expanding it with the SerialID (seen udev documentation) and modifying it to NAME="video0" that camera will become /dev/video0

Other entries afterwards with a changed serial id and a higher videoX entry will enable static assignment.

udev developers call it persistent mode.

 

Hope that helps a bit.


  • cwilt, LS-Support-12 and woodtore like this

#4 woodtore

woodtore

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 22 March 2015 - 11:12 AM

Wow Thank you very much for your time. I hope later on today I will get to sit down and apply it. Thank you.

 

Torey



#5 cwilt

cwilt

    Advanced Member

  • Members
  • PipPipPip
  • 1,012 posts

Posted 22 March 2015 - 02:00 PM

Excellent post nunja.



#6 woodtore

woodtore

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 22 March 2015 - 02:39 PM

Attached is my syslog.

 

Logitech QuickCam Communicate STX VID 046d PID 08d7 USB 3-1.2 SerialNumber ?

Logitech QuickCam E 3500                          046d        09a4         3-1.1                        168F6B40

 

On the line at [    6.591933] it says "usb 3-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0" while on line [    6.165788] it says "usb 3-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=2".

 

I think that you imply that the serial isn't necessary in my instance because of the different PID but in the interest of teaching a man to fish... Why doesn't usb 3-1.2 have a serial number? And does the "SerialNumber=0" indicate the lack of Serial Number and "SerialNumber=2" indicate the presence of a Serial Number?

Attached Files



#7 nunja

nunja

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts

Posted 24 March 2015 - 11:53 AM

woodtore

 

As I understand reading your supplied syslog.txt you're connected one camera that uses the gspca driver and the other camera uses the uvc driver.

The one connected to usb 3-1.2 seems to be the gspca driver and doesn't give you a serial number.

 

First off all let me point out from experience that it is not a good idea to integrate USB cameras into a multimedia environment that require to load a mix of drivers. Such mix most of the time will result in various small problems with applications and may be hard to fix because the error can not exactly be traced.

It's better to use a range of cameras of one or more manufacturers - price :) - that require the same type of driver.

In your case I would replace the gspca camera against an uvc camera because uvc is more common and gspca is hardly maintained.

 

However, to answer your question in your case you do not need to integrate the serial number scheme into the usbdev rule set because your system is using a mix of drivers.

 

The missing serial number for the gspca device might have more than one cause.

Either the manufacturer failed by not giving a serial number

or the camera entries in the gspca drivers fail to read thereby not handling the number to the USB system

or an entry for such came can not be read due  to missing instances in the USB ID system.

I suppose the first one is correct.

 

Hope that helps.


  • LS-Support-12 and woodtore like this

#8 woodtore

woodtore

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 02 October 2015 - 01:59 AM

I have done this on a few different devices and each one seems a little different. Here is a link for some very useful info regarding udev rules. http://www.reactivat...es.html#builtin

 

One really handy command that I have found is "udevadm info --attribute-walk --name=/dev/video0". This assumes that your device is already at /dev/video0. This command allows you to figure out some attributes to put in your rule.


  • cwilt likes this

#9 cwilt

cwilt

    Advanced Member

  • Members
  • PipPipPip
  • 1,012 posts

Posted 02 October 2015 - 02:13 AM

Thanks for the information.



#10 LS-Support-12

LS-Support-12

    Forum Support

  • Moderators
  • 326 posts

Posted 03 October 2015 - 04:51 AM

I am running motion on boot...

Sorry for asking, but I don't understand this part. Could you explain it a bit?

 

Also, have you solved your problem or found some workaround?



#11 woodtore

woodtore

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 04 October 2015 - 03:45 AM

Sometimes I have it set up to run a command like "motion &" within /etc/rc.local. Other times I have keyboard access after boot and can manually start motion but really it doesn't matter when motion is started. It gets tiresome editing the config files when the device isn't persistent. For those unfamiliar with motion it can be reviewed here.

 

Making a udev rule is in my opinion the correct way to achieve what I was trying to do, no workaround needed.


  • LS-Support-12 likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users