assigning permanent device nodes to video devices?
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
assigning permanent device nodes to video devices?
Hi all,
I have two video devices in my system, a webcam and a TV card. Sometimes the first is /dev/video0, sometimes the second is, depending for example on whether the webcam is plugged in.
Is it possible to assign a permanent device node to a given device, such as you can do with udev rules?
Searching a few months ago with Google, I thought I found the answer, but now I am unable to.
1. Go to the /sys directory and find your devices in a subdirectory (I usually look under 'class') for example:
cd /sys/class/video4linux
ls
radio0 vbi0 video0
Now I look at information on 'video0':
udevinfo -a -p ${PWD}/video0
looking at device '/class/video4linux/video0':
KERNEL=="video0"
SUBSYSTEM=="video4linux"
DRIVER==""
ATTR{name}=="cx88_0_ video _Hauppauge WinTV-"
ATTR{dev}=="81:0"
(and a lot more info that I don't need to post)
In my case the "ATTR{name}" is enough to identify my video device, so I can make a udev rule that looks like this:
ATTR{name}=="cx88_0_ video _Hauppauge WinTV-", NAME="v4l/video0"
Be careful with clashes with existing rules:
cd /etc/udev
fgrep -r "v4l" *
fgrep -r "video" *
You may want to comment out a generic rule like:
KERNEL=="video[0-9]*", NAME="v4l/%k"
and create your own rules file that looks something like this:
ATTR{name}=="cx88_0_ video _Hauppauge WinTV-", NAME="v4l/video0", GOTO="video_naming_end"
ATTR{name}=="mywebcam", NAME="v4l/video1", GOTO="video_naming_end"
KERNEL=="video[0-9]*", NAME="v4l/%k"
LABEL="video_naming_end"
That set of rules will skip the default naming done by "KERNEL==" if the device matches either of the previous two.
You may also need to force udev to update its rules:
/etc/init.d/udev reload
Re-editing udev rules has its own disadvantages. One is a device node may not be able to create. When your distribution updates udev, your custom udev rules may not work. In these distributions you have to create or use file that your distributor recommends on using for creating custom udev rules.
The best route to take is to specify video_nr or something similar as a module option if video capture devices uses different modules. It will set each device to a device node number every time the computer boots up or the module is reloaded.
Sometimes, you need a device to always be called the same. Udev reads rules from /etc/udev/rules.d/, it reads all the files there, ordering them lexically (the numbers in front of their name is a convenient and more human readable way to make emphasis on that), so as long as you create a file called 99-something and the name doesn't match this of a previously existing file, you shouldn't have problems when updating.
Udev updates do not happen everyday either.
This makes it possible to have custom automount scripts for my external drives without the need for ugly stuff like ivman, which just gives trouble (and no, I don't use mainstream desktops either, whatever they use to automount nowadays).
Udev reads rules from /etc/udev/rules.d/, it reads all the files there, ordering them lexically (the numbers in front of their name is a convenient and more human readable way to make emphasis on that), so as long as you create a file called 99-something and the name doesn't match this of a previously existing file, you shouldn't have problems when updating.
Should one's custom rulesets be loaded first or last? At the moment, mine is called with 09-local.rules, which I think places it first. 99- is already taken in my distro by 99-fuse.rules
I do not recommend editing udev rules because each distributions require you to use a certain file to create custom rules. I strongly recommend you add something similar of the following lines to either a file in /etc/modules.d, /etc/modules.conf, or a similar file depending on your distribution.
options module_name video_nr=X
This is the easiest way and preferred way than just messing around in udev scripts to change the device node for each card. The X designates the device node number. The value 0 will be the first card and 1 will be the second card.
What pinniped and i92guboj have provided is informative, but may not work in all cases. Again each distribution may require you to use a certain file to store your custom udev rules. For example in Gentoo /etc/udev/rules.d/XX-local.rules is used to hold custom udev rules and the X designates the priority that udev loads first to last.
I recommend use udev to help you make symbolic links to a certain device node. If my Hauppauge PVR-250 is assigned at /dev/video0, and I want it name to something else, I would add code to make udev create a symbolic link named hauppaugepvr250_XX or hauppaugepvrtwofiftyXX or hauppaugepvr250 that points to /dev/video0.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.