Bug 177650

Are the devices still under /proc/bus/usb used?

ISTR reading that Something Else was supposed to be done, in conjunction with
udev. Lemme see if I can dig up the ref.

Aha.

http://sourceforge.net/mailarchive/message.php?msg_id=12695893

Yes. Running xsane as root and then looking at the file descriptors it has open
shows that it's using /proc/bus/usb/004/014

OK, here's some stuff to test. Please:

a) install the attached udev rules file in /etc/udev/rules.d
b) rebuild the attached libusb, and install it
c) *unmount* /proc/bus/usb
d) reconnect your scanner

Then please report:
1) does sane use the device nodes in /dev/ instead of /proc?
2) does udev create /dev/scanner-XXX devices
3) does this cause pam_console to chmod the /dev usb devices to the right owner?
4) does the right thing happen on disconnect?

Sorry, I don't have hardware to test this with. :/

Created attachment 123351 [details]
udev rules file

Created attachment 123352 [details]
patched libsusb

CCing Nils and Tim - if this works, we need this for FC5. Should solve 121511 as
well. Basically, this makes libusb use the device nodes that udev creates,
rather than the stuff in usbdevfs, and adds udev rules for the scanners
(formerly in the usermap) to create scanner symlinks that pam_console will then
follow.

The udev rules was simply done with:

cat libsane.usermap | awk '{ print $3 $4 }' | while read v d ; do
  echo ".... SYSFS{vendor}=$v, SYSFS{device}=$d, ...."
done

This should be easily scriptable in the spec, at least. (There's some other
stuff in core/extras that probably needs this too.)

However, I don't have any hardware to test this with. More eyes/guinea pigs
needed. :)

I'm not going to be back home where the hardware is until February, but I'll
test it then if nobody's done so beforehand.

Adding new libusb maintainer to CC.

*** Bug 121511 has been marked as a duplicate of this bug. ***

I have tried the steps in comment #4, with no success.  The /dev/scanner-XXX
nodes are not created.  IIRC from the days of bug #121511, udev rules can't
help, because libusb devices don't create a udev event.

Note also that any solution much cover two different scenarios -- cold-
plugging (or hotplugging when no console user is logged in) and hotplugging
when a console user is logged in.  In the second scenario, I believe that
pam_console won't normally get called.  Once upon a time, one of the USB
hotplug scripts automatically set the permissions to the current console
user, if there was one.  While this worked, it meant that the ownership
policy for USB scanners was stored in two places (and was hardcoded in one
of them).  Needless to say, this is bad.

(In reply to comment #11)
> I have tried the steps in comment #4, with no success.  The /dev/scanner-XXX
> nodes are not created.  IIRC from the days of bug #121511, udev rules can't
> help, because libusb devices don't create a udev event.

That's what this is intended to fix - moving to actual, udev-created, devices.
The scanner-XXX stuff is just symlinks so pam_console works.

If you run udevmonitor before attaching the scanner, what output does it print
on attach?

> Note also that any solution much cover two different scenarios -- cold-
> plugging (or hotplugging when no console user is logged in) and hotplugging
> when a console user is logged in.  In the second scenario, I believe that
> pam_console won't normally get called.

This *should* solve that (when it works), as when you hotplug, udev will create
the device nodes/symlinks, and then check them with pam_console.

Here is the output from udevmonitor (plug & unplug):

UEVENT[1137719855.369193] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UEVENT[1137719855.369282] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UEVENT[1137719855.369317] add@/class/usb_device/usbdev2.3
UDEV  [1137719855.372659] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UDEV  [1137719855.479858] add@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UDEV  [1137719855.591790] add@/class/usb_device/usbdev2.3

UEVENT[1137719878.674995] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UEVENT[1137719878.675597] remove@/class/usb_device/usbdev2.3
UEVENT[1137719878.675629] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2
UDEV  [1137719878.676949] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0
UDEV  [1137719878.701976] remove@/class/usb_device/usbdev2.3
UDEV  [1137719878.724143] remove@/devices/pci0000:00/0000:00:1d.1/usb2/2-2

Definitely no /dev entries, though.

Oh, hm. I suspect what's happening is that when it's triggering on the
/class/usb_device/usbdevXX devices, the vendor and device id files aren't in
that directory.

Oops. What happens if you do s/vendor/idVendor/ and s/device/idProduct/ to the
rules file?

I think you want 's/{device}/{idProduct}/'.  Otherwise, it catches the
'SUBSYSTEM=="usb_device"' portion of each line.

So my rules file now has lines which look like:

ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}==0x03f0,
SYSFS{idProduct}==0x0405, SYMLINK+="scanner-usb-%k"

The output from udevmonitor is the same as above (except that it's usbdev2.2
this time, probably because it was the first time I plugged in the scanner
since rebooting).

I did notice, however, that a device node /dev/usbdev2.2 appeared when I
plugged the scanner in and disappeared when I unplugged it.  I honestly
don't know if that happened previously, since I was only looking for
/dev/scanner-XXX entries.

BTW, I have verified that my scanner (04b8:0110) is listed.

Sorry, I hate to do this back-and-forth debugging like this, but what happens if
you change it from:

 SYSFS{idVendor} ... SYSFS{idProduct}

to:

 SYSFS{device/idVendor} ... SYSFS{device/idProduct}

?

Same result.  Looking at the output of udevmon --env, it looks like the rule
might work (with SYSFS{idVendor} and SYSFS{idProduct}) if the SUBSYSTEM were
specified as "usb", rather than "usb_device".  In this case, DEVICE points to
the /proc/bus/usb... file, but that would work with an unpatched libusb,
wouldn't it?

Not really, because we don't want to rely on usbdevfs.

In that case, if I'm correct than SYSFS rules won't work with relative paths
like that, I think that you're going to need a helper program.

Well, we have rules in the current config with relative paths, so I sort of
assumed they *did* work. I should check that. :)

New libusb-0.1.11 is now built in rawhide btw. Not sure whether it helps here
somehow though.

Not using my scanner since bug 121511 seemed to fix the operation of the scanner
to work with the console user, I will try the scanner with present FC5T2 on a
different computer.
Hardware: HP ScanJet 2100C
Adding to self CC:

Created attachment 123688 [details]
new rules file

This rules file (in conjunction with the patched libusb) should fix it. I'll
build a new sane-backends.

Since scanners also use libusb and also use /dev/bus/usb they will have
the problem found in bug 178543, and need the first part of the patch
I did against libusb (to support [0-9A-F]+ device node names) to work 
properly as of now. (I think.)

Bill, can you get this and the other patch into the libusb-0.1.11 at
rawhide so we have a working system until upstream indicate how we shall
solve it?

Linus, could you file a separate bug against libusb with the required patches
and add a reference to it here?

Well I sent a mail off to both libusb-devel and linux-hotplug-devel
to have the situation sorted out. Let us see what they say.

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...

The resolution of this bug depends on bug 178994.
The modified RPM by Bill has this fix...

Should be fixed with current rawhide libusb (0.1.11-2), sane-backends
(1.0.17-3), and udev (078-8).

Yeah, this works again on a clean rawhide-20060206 install. Well, it works with
the 'hp' sane backend. The 'hpaio' backend segfaults but at least it doesn't do
it at _probe_ time; only if I make the mistake of using it. qv. 

dwmw2: please file an HPLIP bug for the hpaio backend segfault.  Thanks.

I think I already filed it, although against sane. Hence the 'qv'.

I've to admit my ignorance: what does 'qv' mean?

It's used in dictionaries etc. to indicate that whatever is being discussed has
a separate entry of its own. I believe it's from the latin 'quod vide' (see which).

fails on rawhide-20060307, and even root cannot find the HP device any more.
Possibly not the same problem?

Possibly not. Is it seen with lsusb, etc? Do the devices exist under /dev/bus/usb?

Is libusb actually trying to look at them (check with strace, etc.)