| Summary: | TV Card and Webcam switch /dev/video1 and /dev/video0 on reboots if a webcam is pluged | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marc Paré <marc> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | chmielu1_a, dmorganec, mageia, mageia, marja11, sysadmin-bugs, thierry.vignaud, tmb |
| Version: | 1 | Keywords: | Triaged |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| URL: | http://forum.mandriva.com/en/viewtopic.php?f=10&t=64910 | ||
| Whiteboard: | |||
| Source RPM: | udev | CVE: | |
| Status comment: | |||
|
Description
Marc Paré
2011-11-01 07:00:54 CET
Hi, I had a similar problem... I solved it http://www.fotosik.pl/pokaz_obrazek/pelny/8c1582645d1a73ad.html It is now: $ cat /etc/modprobe.conf ... options cx8800 video_nr=1 $ CC:
(none) =>
chmielu1_a Thanks, this does solve the problem of changing the videoX line in the TVTime.xml file at every boot-up. However, this does not solve the original problem of Mageia not identifying the PCI and then USB cards in the right order at boot up. I take care of approximately 15 Mageia setups for friends (some older in age) and if they plug in a USB webcam, their TV cards will no longer work. I would have to mod. their TV card setup each time. Plus, I have another approximately 30 Mageia setups coming on board before the end of the year. I am switching them all from Mandriva 2010.2 to Mageia. There must be a way to fix this so that the detection of cards and USB devices is better implemented. Marc BTW -- Thanks for the MCC image capture that you included in your last post. This really helped. Hi, thanks for reporting this bug. Thierry, I guess it's ldetect ? Keywords:
(none) =>
Triaged No. CC:
(none) =>
thierry.vignaud, tmb
Thierry Vignaud
2011-12-10 04:22:02 CET
CC:
(none) =>
mageia cc'ing two more udev committers @ Colin You're aware that Thierry cc'ed you before? CC:
(none) =>
dmorganec, mageia, marja11 I'm not really sure what the offical fix for this should be, but kernel level module loading has just landed so perhaps this will offer some more sane defaults. I'll try and ask Kay if it's something that might help this problem. Col OK, so the latest stuff in kernel land won't help. Hey how. But, having poked around a bit, this is exactly the same problem as hard disks with the /dev/sdX device nodes. Nowadays we prefer UUID to access disks as it avoids this problem. udev does a lot of work to create more static symlinks for devices e.g. for disks, the /dev/disks/by-* folders contain links by uuid, by label etc. With video devices, there are also some links... they might not be visible for all devices so this might not always work, but try this: Say you want to use what is currently /dev/video0... run the following command: udevadm info -n /dev/video0 -qall | grep DEVLINKS for me with some crappy camera plugged in I get: E: DEVLINKS=/dev/v4l/by-id/usb-STMicroelectronics_USB_Dual-mode_Camera-video-index0 /dev/v4l/by-path/pci-0000:00:1d.7-usb-0:7.5:1.0-video-index0 So in this case, the link: /dev/v4l/by-id/usb-STMicroelectronics_USB_Dual-mode_Camera-video-index0 Now I'm hoping the "index0" suffix here does not refer to it's actual index (as in video0) but I only have one device here to test with so I'll have to wait and see when I get home whether this name is truly static. Anyway, in theory at least, it should be more static than /dev/video0... maybe this helps? @ Colin Since you're working on this bug, being brutal and assigning to you. :þ Please assign back to bugsquad if my brutality offends you. Assignee:
bugsquad =>
mageia @ Marja Don't worry :). I suspect it'll be a WONTFIX anyway, but I'm curious to see if the links do actually solve the problem. Status:
NEW =>
ASSIGNED OK, tested at home, and for me at least, the symlinks are static. The index0 suffix would appear to handle the case where two devices have the same usb-id. Tested with two completely different cameras and the symlink name remained static regardless of the order of insertion and thus regardless of whether it was video0 or video1. Sadly I also tried with two identical cameras and the symlink was overwritten for the second device... (i.e. an index1 suffix was not used...) Not sure if this is a bug or not, but will ask Kay or some v4l folks. Either way, if you have two different devices (as in this case) I'm pretty sure the symlinks in /dev/v4l/ are the way to go rather than directly using /dev/videoN. Therefore, closing this bug as wontfix until any other information might change that resolution. Status:
ASSIGNED =>
RESOLVED |