I have a Dell laptop with an integrated webcam which works with the 'uvcvideo'
module. For kernel versions 2.6.27 and below the following udev rule:
KERNEL=="video[0-9]*", NAME="v4l/video%n", SYMLINK+="%k", GROUP="video"
would create '/dev/video0' as a link to '/dev/v4l/video0'. When switching to
2.6.28 the rule creates '/dev/video1394-0' instead. Obviously most user-space
apps were quite surprised by this (as was I).
Is this change intended or is it the accidental result of some modification ?
(attached 'lsusb' information for the device)
On Tue, Jan 20, 2009 at 12:49, Ionut Leonte <[email protected]> wrote:
> I have a Dell laptop with an integrated webcam which works with the 'uvcvideo'
> module. For kernel versions 2.6.27 and below the following udev rule:
>
> KERNEL=="video[0-9]*", NAME="v4l/video%n", SYMLINK+="%k", GROUP="video"
>
> would create '/dev/video0' as a link to '/dev/v4l/video0'. When switching to
> 2.6.28 the rule creates '/dev/video1394-0' instead. Obviously most user-space
> apps were quite surprised by this (as was I).
>
> Is this change intended or is it the accidental result of some modification ?
These rules are broken, and match also on firewire devices and not
only video4linux devices.
Such rules are not part of the standard udev setup and need to be
fixed to work as intended. There is no change or fault at the kernel
side. You may just disable the firefire drivers if you don't need
them.
Btw, swapping default kernel names to devfs names and create symlinks
for the kernel names is not recommended at all.
Kay
On Tuesday 20 January 2009 15:07:21 you wrote:
> These rules are broken, and match also on firewire devices and not
> only video4linux devices.
>
> Such rules are not part of the standard udev setup and need to be
> fixed to work as intended. There is no change or fault at the kernel
> side. You may just disable the firefire drivers if you don't need
> them.
>
> Btw, swapping default kernel names to devfs names and create symlinks
> for the kernel names is not recommended at all.
Thanks for the clarifications. The rule is taken from the 'default' udev setup
as presented to me by my distribution (Gentoo in my case). I'll be sure to
file a bug report with them.
Cheers.
Kay Sievers wrote:
> On Tue, Jan 20, 2009 at 12:49, Ionut Leonte <[email protected]> wrote:
>> I have a Dell laptop with an integrated webcam which works with the 'uvcvideo'
>> module. For kernel versions 2.6.27 and below the following udev rule:
>>
>> KERNEL=="video[0-9]*", NAME="v4l/video%n", SYMLINK+="%k", GROUP="video"
>>
>> would create '/dev/video0' as a link to '/dev/v4l/video0'. When switching to
>> 2.6.28 the rule creates '/dev/video1394-0' instead. Obviously most user-space
>> apps were quite surprised by this (as was I).
>>
>> Is this change intended or is it the accidental result of some modification ?
>
> These rules are broken, and match also on firewire devices and not
> only video4linux devices.
>
> Such rules are not part of the standard udev setup and need to be
> fixed to work as intended. There is no change or fault at the kernel
> side.
Exactly.
> You may just disable the firefire drivers if you don't need them.
It is not even necessary to disable the drivers; it would be sufficient
to not force-load the video1394 module. (Or to fix the udev rule.)
Presence of a Firewire card does not cause video1394 to be auto-loaded;
only certain types of FireWire cameras cause respective uevents and thus
autoloading of the special-purpose driver video1394. Ergo, Ionut's
userland has a configuration somewhere which loads video1394 explicitly.
> Btw, swapping default kernel names to devfs names and create symlinks
> for the kernel names is not recommended at all.
>
> Kay
--
Stefan Richter
-=====-==--= ---= =-=--
http://arcgraph.de/sr/
On Tuesday 20 January 2009 19:13:45 you wrote:
> Kay Sievers wrote:
> > You may just disable the firefire drivers if you don't need them.
>
> It is not even necessary to disable the drivers; it would be sufficient
> to not force-load the video1394 module. (Or to fix the udev rule.)
> Presence of a Firewire card does not cause video1394 to be auto-loaded;
> only certain types of FireWire cameras cause respective uevents and thus
> autoloading of the special-purpose driver video1394. Ergo, Ionut's
> userland has a configuration somewhere which loads video1394 explicitly.
It's most likely related to my kernel being monolithic - the only modules I
have are out-of-tree ones (like the binary nvidia driver and ndiswrapper).
Perhaps it's time I reconsidered my monolithic aproach to kernel building and
start compiling stuff as modules again.
Ionut Leonte wrote:
> On Tuesday 20 January 2009 19:13:45 you wrote:
>> only certain types of FireWire cameras cause respective uevents and thus
>> autoloading of the special-purpose driver video1394. Ergo, Ionut's
>> userland has a configuration somewhere which loads video1394 explicitly.
>
> It's most likely related to my kernel being monolithic -
Ah, right; I keep forgetting that there is also Y besides M. :-)
Anyway, the best course of action is to get the udev device naming rules
fixed.
I suppose the simplest course of action would be to add the expression
SUBSYSTEM=="video4linux" to the v4l rule. Then it won't be applied to
ieee1394 devices.
--
Stefan Richter
-=====-==--= ---= =-=-=
http://arcgraph.de/sr/