The apcupsd ebuild uses /dev/usb/hiddev[0..9] in it's compile flags this is incorrect as 2.4.29 and 2.6.10 atleast allready use /dev/usb/hid/hidev[0..9] Reproducible: Always Steps to Reproduce: 1.emerge apcupsd Actual Results: the ebuild configures USB-hid directory as /dev/usb/hiddev[0..9] Expected Results: the ebuild should configure the current USB-hid directory, /dev/usb/hid/hiddev[0..9]
Are you sure? I'm running linux-2.6.11-gentoo-r6, and it uses /dev/usb/hiddev[0..15]. See <Documentation/usb/hiddev.txt>. Anyway, I'd expect this to be controlled by udev (or whatever manages /dev for you) rather than the kernel, and my </etc/udev/rules.d/50-udev.rules> puts the device nodes directly into /dev/usb/. (I'm running udev-045.) I have heard of machines having a /dev/usb/hid/ directory like you describe, but I haven't found what they have in common. I figured that this bug was that apcupsd.conf refers to hiddev[0..9] rather than hiddev[0..15] as the big comment in the file recommends.
thanks Matthew udev's rules do create /dev/usb/hiddev*: KERNEL="hiddev*", NAME="usb/%k" i'll leave it up to tantive to close out the bug
well i'm still using devfsd so that might be a reason? Isn't there a way to probe/ask the system where it is?
Yeah, it looks like devfs is probably the issue, though I can't find a definitive source. No, there's no reasonable way to ask the system where hiddev* would be placed. At best (?), you could configure devfs/udev to create symlinks so that both nodes appear, but it's not worth it. Devfs is going away in July (see <Documentation/feature-removal-schedule.txt>), and /dev/usb/hiddev[0-15] is apparently the current standard location, so I think this is just the way it has to be.
Damnit, I still use devfs because last time I checked I couldn't use udev out of the box. Oh well guess i'll try again. I suppose we can close this bug then.