Re: [gentoo-amd64] Re: USB Scanner Problems with Newer Kernels/Libusb [Solved]

[Frank Peters <frank.peters@comcast.net>]

On Sat, 9 Nov 2013 12:29:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>  
>  udev creates usb devices in /dev/bus/usb.  Each usb port is a (three-digit
> sequentially numbered) directory,
> Libusb, meanwhile, has been updated to work with the /dev/bus/usb/ tree, 
> so AFAIK that's what you need to create... somehow.
>

On Sat, 9 Nov 2013 16:11:48 -0600
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> 
> Maybe you can run it once even as a non-daemon just to create the
> device, similarly to running rescan-scsi-bus.
> 

Well, it works!  That is, I can start udev as a daemon, plug in my
scanner, and udev will tell me what the major and minor numbers of the
scanner device node.  Then I can use my scanner with libusb and SANE.

I thought that udev would also create the device node, but for some
reason it does not.  However, I can create the device manually in the /dev
tree and then SANE is able to detect the scanner.

Thanks especially to Duncan for his info on the /dev/bus/usb/001 ...
location.  I can manually create, for example, /dev/bus/usb/001
using the major/minor numbers reported by udev.  Then I am in
business for scanning.

Actually, I can just create a whole series of nodes under /dev/bus/usb
with the same major number and an incremental minor number.  This
will eliminate the need to use udev entirely.  Whenever I plug in my
scanner one of those nodes will be relevant.

But the whole process illustrates that udev is not really necessary.
The scanner is accessed through a device node in the /dev tree
and there is no reason why udev must create this node.  As long
as the major/minor numbers are known (and the char or block characteristic)
then anything can create the node.  IOW, the kernel access is the
same as always.  Only these user space programs impose these node
constraints.

I wonder if I can determine the major/minor numbers in some other way.
Maybe the /sys tree has that information.  If so, then I could
completely script the process without using udev.

Thanks to all for the contribution.

Frank Peters