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

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

On Sat, 9 Nov 2013 19:53:02 -0600
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> 
> I figured as much. Please let us know if you come up with a good
> technique that can be adapted to a MAKEDEV script or such. It is nice
> to know how to dump e?udev, just in case; and I also use a scanner.
> 

As soon as I plugged in the scanner (after starting the udev daemon)
an entry was created in /run/udev/data for c189:131.  This obviously
refers to a device node for a character (c) file with a major number
of 189 and a minor number of 131.  This is all that is needed to access
the device through the kernel.

However, with udev and libusb there are user-space conventions.
A utility such as libusb expects device nodes to be in a certain
location, i.e. /dev/bus/usb, and to be named a certain name, i.e.
001, 002, etc.  If not for these conventions the device node could
be placed anywhere and named anything.

So, to stick to conventions, create the node in /dev/bus/usb:

mknod --mode=0666 /dev/bus/usb/001 c 189 131

That's it.  Now the scanner can be detected by libusb and SANE.
Furthermore, this is a *permanent* device node.  It will not
disappear upon reboot.  The udev daemon is needed only once
to get the major/minor numbers.

However, if the device is unplugged and then plugged back in again
the minor number usually jumps.  So just create a sequence of
nodes to allow for this:

mknod --mode=0666 /dev/bus/usb/002 c 189 132
mknod --mode=0666 /dev/bus/usb/003 c 189 133 ...

Upon reboot, the node will reset back to the first minor number.

If you check devices.txt in the kernel source documentation, these
particular major/minor numbers are not listed for any device.  I don't
know where they come from, but as long as they work I don't care.
However, this would preclude using something like MAKEDEV to pre-build
these nodes.  Also, user-space programs expect certain node naming
conventions and I don't know where such conventions are listed.

A new issue is determining how udev gets its device info.  The kernel
sends out a notice when it detects a new device and the udev daemon
gets the notice and then reads the new kernel device parameters
from somewhere.  But from where?  If this were known then any script
could read the same parameters.

In short, if udev reads data from the kernel then a simple custom
program or script could accomplish the same thing.

Frank Peters