2 kernels, 2 different mice locations
Hi,
I'm using 2 kernels on my distribution. The "official" one is 2.6.32, and I'm providing a 2.6.29.6-rt24 for those who want to use RealTime. But since we upgraded udev to the latest version, some of /dev files are placed at different locations depending on which kernel is used.
With 2.6.32, everything works fine, but now, when I boot with 2.6.29.6-rt24, I cannot move my mouse unless I symlink /dev/mice to /dev/input/mice. And it doesn't completely work, because I'm unable to scroll.
I'm not familiar with udev, so I don't really know why older kernels don't seem to be able to use udev the same way. I tried with the development version of the RT kernel, which patches 2.6.31, and all worked fine.
Can you give me some clues to make my system be able to boot right with my RT kernel?
Thanks in advance,
Aymeric.
2010/2/17 Aymeric O. <[email protected]>:
Quoted 9 lines
I'm using 2 kernels on my distribution. The "official" one is 2.6.32, and I'm providing a 2.6.29.6-rt24 for those who want to use RealTime. But since we upgraded udev to the latest version, some of /dev files are placed at different locations depending on which kernel is used.
With 2.6.32, everything works fine, but now, when I boot with 2.6.29.6-rt24, I cannot move my mouse unless I symlink
/dev/miceto/dev/input/mice. And it doesn't completely work, because I'm unable to scroll.
New udev versions and old kernels need some old udev rules to name device nodes. You should be able to use the Gentoo rules, which seem to support this:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEAD
Kay
That did the trick!
I will be able to provide a new stable RT kernel, now.
Thank you very much!
Quoted 19 lines · Kay Sievers
2010/2/17 Aymeric O. <[email protected]>:
Quoted 10 lines
I'm using 2 kernels on my distribution. The "official" one is 2.6.32, and I'm providing a 2.6.29.6-rt24 for those who want to use RealTime. But since we upgraded udev to the latest version, some of /dev files are placed at different locations depending on which kernel is used.
With 2.6.32, everything works fine, but now, when I boot with 2.6.29.6-rt24, I cannot move my mouse unless I symlink
/dev/miceto/dev/input/mice. And it doesn't completely work, because I'm unable to scroll.New udev versions and old kernels need some old udev rules to name device nodes. You should be able to use the Gentoo rules, which seem to support this:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEADKay
I just noticed raw1394 is owned by the "root" group, but it should be owned by "disk" so it could be used by a regular user. This problem occurs with both kernels. Is it a udev problem or should our udev be added some rules to solve this?
Quoted 19 lines · Kay Sievers
2010/2/17 Aymeric O. <[email protected]>:
Quoted 10 lines
I'm using 2 kernels on my distribution. The "official" one is 2.6.32, and I'm providing a 2.6.29.6-rt24 for those who want to use RealTime. But since we upgraded udev to the latest version, some of /dev files are placed at different locations depending on which kernel is used.
With 2.6.32, everything works fine, but now, when I boot with 2.6.29.6-rt24, I cannot move my mouse unless I symlink
/dev/miceto/dev/input/mice. And it doesn't completely work, because I'm unable to scroll.New udev versions and old kernels need some old udev rules to name device nodes. You should be able to use the Gentoo rules, which seem to support this:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEADKay
Quoted 4 lines · Aymeric O.
I just noticed raw1394 is owned by the "root" group, but it should be owned by "disk" so it could be used by a regular user. This problem occurs with both kernels. Is it a udev problem or should our udev be added some rules to solve this?
Default installations don't want that, because of security concerns with firewire and DMA access.
The old firewire stack is deprecated now and replaced with new drivers, so these rules will not be there for very long anymore.
No regular user should ever be in the group "disk". It will allow to reformat all system partitions. Historically "disk" is more for backup programs.
Also raw1394 has not much to do with "disk". :)
Kay
So that means that libraw1394
(http://sourceforge.net/projects/libraw1394/) must be up to date from now on? If so, I will ask its maintainer for it.
Quoted 21 lines · Kay Sievers
Quoted 5 lines · Aymeric O.
I just noticed raw1394 is owned by the "root" group, but it should be owned by "disk" so it could be used by a regular user. This problem occurs with both kernels. Is it a udev problem or should our udev be added some rules to solve this?
Default installations don't want that, because of security concerns with firewire and DMA access.
The old firewire stack is deprecated now and replaced with new drivers, so these rules will not be there for very long anymore.
No regular user should ever be in the group "disk". It will allow to reformat all system partitions. Historically "disk" is more for backup programs.
Also raw1394 has not much to do with "disk". :)
Kay