Seems Fedora is going the same way as SuSE, removing hotplug in favor of
just using udev.

Does anyone have a good primer on how to write proper udev rules for custom
(i.e. non standard-class) USB devices?

hotplug has been actually mostly removed for a while now, but there's been a
package that has "Provides: hotplug" until now.

I don't know of a good primer, but openct in Extras (devel branch) is one
example package where legacy hotplug functionality has been converted to use udev.

Making some thinking aloud.

Yeah I looked into openct in CVS... Perhaps I can use this stuff:
http://www.reactivated.net/writing_udev_rules.html

If I supply rules like this for every device in libnjb.rules:

SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4100", MODE="0666"
...

Add them into the RPM with:

Source1: libnjb.rules

%install
install -Dpm 644 \
  %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/udev/rules.d/60-libnjb.rules

%files
%config(noreplace) %{_sysconfdir}/udev/rules.d/*libnjb.rules

That should work... Will need a device to do some testing, later this
week.

mode=0666 does not sound too good to me, but then again, I know nothing about
libnjb.  Maybe you can use udev's pam_console integration to provide more access
to those devices for logged in users only?  I *think* it would be a matter of
dropping in a /etc/security/console.perms.d snippet for those devices (assuming
udev does create them with _some_ permissions).

Using udev for this one is a real pain... Since libnjb access the
device in user-mode using libusb it does not use any kernel modules
and such. This means it access the device thorugh usbfs mounted at
/proc/bus/usb (or /sys/bus/usb) and when the device appears the
current hotplug script change permissions on its node, for example
/proc/bus/usb/001/001.

However udev seems to imply that everything and its mother has a 
kernel driver or is a block device and work from there, making rules 
very hard if not impossible to write.

Any hints?

No real hints, sorry.  Note however, FWIW, that openct does not have any kernel
modules either, but yet udev can be told to do the right thing with it.  Maybe
ask on the udev mailing list and/or the FC udev maintainer and/or fedora-devel...

I am getting this bug and gnomad seems to be the only required application that
is using this library.
initscripts will not install because of the udev requirement that libnjb requires.

This is probably altogether a different bug case than described. Udev was
removed libnjb requires udev. Should I file a seperate bug report.

(In reply to comment #5)
> Using udev for this one is a real pain... Since libnjb access the
> device in user-mode using libusb it does not use any kernel modules
> and such. This means it access the device thorugh usbfs mounted at
> /proc/bus/usb (or /sys/bus/usb) and when the device appears the
> current hotplug script change permissions on its node, for example
> /proc/bus/usb/001/001.

See bug 177650 for how we're tracking this for SANE.

Thanks Bill, clears things up a bit. Following your work,
trying on my own.

OK, experimenting on FC4 I put in a rules file like this:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nomad_rules_end"

# Creative Nomad Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411e", MODE="660", GROUP="linus",
RUN="/home/linus/bin/boxplugin"

LABEL="nomad_rules_end"

It executes and the script is run. In this script i have added 
"env > /tmp/foo.txt" so I can see the environment variables:

PHYSDEVPATH=/devices/pci0000:00/0000:00:14.2/usb1/1-2
SUBSYSTEM=usb_device
DEVPATH=/class/usb_device/usbdev1.42
MINOR=41
PATH=/sbin:/bin:/usr/sbin:/usr/bin
ACTION=add
PWD=/
UDEV_LOG=3
MAJOR=189
MANAGED_EVENT=1
UDEVD_EVENT=1
DEVNAME=/dev/usbdev1.42
SHLVL=1
HOME=/
PHYSDEVDRIVER=usb
PHYSDEVBUS=usb
SEQNUM=758
_=/bin/env

And the device /dev/usbdev1.42 in this case is correctly created
with the correct permissions.

I have also rebuilt libusb 0.1.11 so I have the patch in that will
supposedly find the device in /dev/usbdev1.42. However libusb does
not pick this up. I have also unmounted /proc/bus/usb, so the problem
is that libusb does not find /dev/usbdev*

Looking at the libusb patch sent in from Debian it seems to expect
a hierarchy to traverse below /dev/bus/usb/ but this is not the
case: there are files *begining* with usbdev really. I think the
former hierarchy may be something Debianesque, or that Red Hat got
things wrong, cannot quite see which one.

Need to look closer at this... Modify libusb some also perhaps.

I have /dev/bus/usb/XXX devices here. What udev do you have?

0.58 for FC4... OK trying to upgrade udev too... Perhaps I need a
FC5 test2 box in order to really try this out.

For FC4, try adding the following rule first:

ACTION=="add", SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"

(this is in the FC5t2 udev config)

Well I think its the libusb usb file system detector that is very
simplistic: it will assume there are device files in a dir in case
it contains any valid filedescriptors. So it looks in this order:

/proc/bus/usb  - OK we can unmount that
/sys/bus/usb - this contains subdirs on FC4 so it will stick here
/dev/usb

Does /sys/bus/usb contain files on FC5 too? In case it does, libusb
will need some patching to get this to work.

The patch removes the /sys/bus/usb code, if I'm looking at it right...

I'm confused... There is a patch that mess with some error messages
in the linux.c files in the RawHide package.

This patch however fixes it, but it still won't work for some reason.
Are the device nodes created in /dev/usb not equivalent to /proc/bus/usb
nodes? (Should be?)

Created attachment 123640 [details]
More patching - only /dev/usb left!

Patches out everything apart from /dev/usb

The patch I'm referring to is in the SRPM in 177650; it's *not* in the rawhide
SRPM. Should be /dev/bus/usb...

Ack, sorry I should pay more attention. However I also altered
the udev macro to put the devices under /dev/usb instead of /dev/bus/usb
and it still does not work.

I will try to get a test2 box up tomorrow (midnight in Sweden now...)

For my nomad I get this output from devices:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=041e ProdID=4100 Rev= 0.01
S:  Manufacturer=Creative Technology
S:  Product=NOMAD Jukebox 2
S:  SerialNumber=F4FF09F61F50020F
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

ls -laZ 002
-rw-r--r--  root     root     system_u:object_r:usbfs_t        002

And then running:
 chown jim:disk 002 from the /proc/bus/usb/001 directory allows gnomad to become
functional. I am not sure what the group should be. I just picked disk.

 ls -laZ 002
-rw-r--r--  jim      disk     system_u:object_r:usbfs_t        002

from the /dev/bus/usb/1 directory, I get 1 and 2 for devices.
 ls -laZ 2
lrwxrwxrwx  root     root     system_u:object_r:device_t       2 ->
../../../usbdev1.2
shows the link to usb 1.2 on my laptop. Are you using usb2?

Jim, you are using the /proc/bus/usb interface which is deprecated
in FC5.

I don't know it /proc/bus/usb will still exist though: if it does we
can trigger on "usb" events instead of "usb_device" events to change
permissions on eg /proc/bus/usb/001/nnn, but that was strongly 
discouraged in bug 177650.

I finally found the problem:

the new crazy device node creation script seen in comment #13 will create
a device hierarchy below /dev/bus/usb. However it will use hex figures
so the directories and device nodes will have names in the span [0-9A-F]+
whereas libusb will only accept directories and devices names in the
span [0-9]+. (Perhaps is really even [0-9A-Z]+ I don't know for sure,
haven't looked so close at it.)

Two ways to fix it: the attached patch which modified libusb (warning, also
patches out the ability to use anything else than /dev/bus/usb) or
fix the node creator rule.

Bill: which approach is apropriate for Red Hat?

Another question is why there is this problem, as I understood the patch
and the udev rule was created by the same person... Perhaps s/he never
saw anything else than [0-9]+ on his/her machine.

Created attachment 123686 [details]
Combined libusb patch

Fixed to support /dev/bus/usb only, fixed to support hex
[0-9A-F]+ directories and devices in the device tree.

I *think* fixing the rule might be simpler. But not sure.

So, outside of the changes for the device nodes/libusb itself, what do your udev
rules for libnjb look like?

Kay, see comments #23/#24 - has this changed upstream since you added this?

I'm contacting upstream to have this resolved.

And right now my libnjb rules file is:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="nomad_rules_end"

# Creative Nomad Jukebox
SYSFS{idVendor}=="0471", SYSFS{idProduct}=="0222", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox 2
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4100", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox 3
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4101", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4108", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen USB 2.0
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="410b", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen NX
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4109", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Xtra
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4110", MODE="660", GROUP="jukebox"
# Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4111", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Touch
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411b", MODE="660", GROUP="jukebox"
# Creative Zen (Zen Micro variant)
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411d", MODE="660", GROUP="jukebox"
# Creative Nomad Jukebox Zen Micro
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="411e", MODE="660", GROUP="jukebox"
# Second Generation Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4126", MODE="660", GROUP="jukebox"
# Dell Pocket DJ
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4127", MODE="660", GROUP="jukebox"
# Creative Zen Sleek
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="4136", MODE="660", GROUP="jukebox"
# Third Generation Dell Digital Jukebox
SYSFS{idVendor}=="041e", SYSFS{idProduct}=="412f", MODE="660", GROUP="jukebox"

LABEL="nomad_rules_end"

Need to find the apropriate group/security settings to get the device lifted
with appropriate privileges for the current desktop user thoug. Hints?

Why have the goto there, instead of just matching on SUBSYSTEM=usb_device,
ACTION=add in the rule itself?

Speeds up execution I guess... Came from the script generator found in
sane-backends/tools/udev

So, for console user stuff, create an
/etc/security/console.perms.d/60-libnjb.perms file that looks something like:

<nomad>=/dev/nomad*

<console> 0600 <nomad> 0600 root

and then change your udev rule so instead of setting user/group/permissions, it
just does SYMLINK+="nomad-%k"

That *should* work.

Hey it works... :-)

I have a working solution the day libusb and the udev rule start
playing well with one another. Will build package for the Fedora
Extras and await further action input from the developer lists of
libusb and linux-hotplug (mail sent).

Huh, why have these buzilla's always to be so confusing. :)
I'll try to summarize:

1.
usbdevfs with the files in /proc should go, cause we want the option to apply
acl's for fast-user-switching to the nodes in /dev.

2.
/proc should not be used for stuff like this anyway.

3.
the new nodes are in /dev/bus/usb/<bus>/<device>

4.
the new nodes should look exactly like the ones in /proc

5.
the new nodes are not expected to contain hex or other chars

6.
I have the following rule, which works fine:
  SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; \
  printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0644"

7.  
libusb needs a simple change to look in /dev/bus/usb/ if /proc/bus/usb/
is not found. (That way, you just don't mount usbdevfs and the nodes
in /dev are used. If people run into trouble with broken software, they
can mount usbfs (as long as it is in the kernel) and ulibusb switches
over. I think I sent the libusb patch to Harald long ago.

Does that help? Otherwise please ask back, this should not be an issue, cause
we run this susccessfully for a long time.

Thanks kay, clears things up.

Re: 6 the problem is that Fedora does not have this rule. It has prefixed
    operators with "X" instead of "K" which yields invalid node names.

Re: 7 a patch that makes libusb look into /dev/bus/usb has been merged 
    into libusb. However the udev rule supplied along with this patch
    had the above mentioned problem. All distributions slavishly applied
    this udev rule, resultin in total havoc whenever the characters A-F
    appear in device node names: libusb does not accept those.

Kay has cleared things up on libusb-devel and linux-hotplug-devel.
Device nodes in /dev/bus/usb shall be named exactly as in /proc/bus/usb
the Fedora udev rule creating the nodes was erroneous.

Bug identified in Fedora udev package, Harald Hoyer has fixed it. 

No changes should be needed in libusb. 

Waiting for confirmation that the bug is gone...

Created a libusb bug to make libusb look in the right place
i.e. /dev/bus/usb instead of /dev/usb

Having both the nomad mp3 player and the HP scanner which these two seperate
bugs refer to, is it safe to remove hotplug? (Hung onto because of library
needed by gnomad)
Will the /proc/bus/usb references be removed completely for FC5?

If I am following the report correctly, /dev/proc/usb/ entries should be
identical in format and permissions as the deprecated /proc/bus/usb entries are
with the current setup.
Will I need to make special rules, change device ownerships or will this all be
automated? (hopefully it works without user tinkering)

> is it safe to remove hotplug?

In FC5, and when the patch in bug 178994 has been applied to Rawhide, yes.
Anyway on FC5 yes, because I rebuilt the Extras libnjb package to work 
exclusively with udev and it does not require hotplug anymore...

> Will I need to make special rules, change device ownerships or will this 
> all be automated? (hopefully it works without user tinkering)

It is all automated. PAM rules in /etc/security/ console permissions
give the console user read+write accces to the jukebox.

This should be fixed with current rawhide 
libusb (0.1.11-2) and udev (078-8).

Could someone with a FC5test2 and a nomad/zen/dell dj device using
libnjb please test this and confirm is the package is working as
intended now so we can close this bug?

I'm running FC5T2 and will try the Nomad Jukebox and an HP scanner and report back.
Currently I have the right version of udev but not the same or newer version for
libusb.

libusb-0.1.11-1
udev-078-8
 

I am still experiencing device permission problems. I have the below permissions
for /dev and /proc versions.

The positive note is gnomad now uses the /dev/bus/usb/001/<usbdev> number. I
changed owner for the device to user:root and gnomad2 would recognize the Jukebox.

Added note: The owner for the device was a problem earlier and the behavior is
not related to the hotplug removal. (I still do have hotplug installed, but not
in the rpm database)

ls -laZ *
crw-------  root     root     system_u:object_r:device_t       001
crw-------  root     root     system_u:object_r:device_t       002
[root@cornette-lt 001]# pwd
/dev/bus/usb/001

----
 pwd
/proc/bus/usb/001
[root@cornette-lt 001]# ls -laZ *
-rw-r--r--  root     root     system_u:object_r:usbfs_t        001
-rw-r--r--  root     root     system_u:object_r:usbfs_t        002

Oh. Did you also upgrade to my new libnjb-2.2.4-2 package? (The previous
was libnjb-2.2.4-1.) from the Fedora Extras?

I tested with libnjb-2.2.4-2.fc5 as far as I recall. Testing again to make sure.
I applied updates today and the version might have been the earlier version.

It seems that I did have the earlier version when previously tested. This is
great on the retest. I did not have to mess with any device ownership or
permissions. The Nomad Juxebox 2LX is recognized.

I believe the bug can be closed as resolved. Thanks very much for the fixup for
Nomad operation in Linux.

Happily closing bug, think we helped Red Hat out on this one too, so great
quality benefit from FedoraExtras(TM). :-)

Resolving bug as NEXTRELEASE.