>> = ???
>  = David Brownell

>> Would it be possible (or reasonable) to add an ioctl to usbdevfs which
>> can ask for this information via the /proc/bus/usb/###/### interface? Or
>> should the printer.o module execute a user-space helper app to do this
>> configuration itself?

>IMHO, either of those would be reasonable 2.4 solutions.  I'd likely
>want to see the ioctl, since scenarios have wanted this feature before.
>But that wouldn't work with non-USB printers; "printer hotplug" should
>IMHO happen at some point, too.

      I agree that it would simplify a lot of device management
if there were a general convention by which a kernel interface or
interface could identify the device or devices that it is talking
to, for example:

eth0                    /proc/bus/pci/00/07.1
eth1                    /proc/bus/usb/01/003
/dev/sound/mixer0       /proc/usb/isapnp/03
/dev/telephony/0        /dev/sound/mixer0


        With such a facility, hot plug drivers could much more reliably
tell which devices they actually had added or removed, even if other
hotplug events had occurred in the interim.

        Regarding automatic parallel port device driver loading, I have
working with Tim Waugh to produce an acceptable patch that simplifies
that parallel port IEEE-1284 device ID matching and implements a
parport MODULE_DEVICE_TABLE.  I sent Tim a version in the earlier
AM hours of this morning (Saturday), and Tim seems to like it so far.
Keith Ownes has already integrated my patch for modutils support for
this in the recent releases of modutils, and you can get the matching
"parportmodules" program from
ftp://ftp.yggdrasil.com/pub/dist/device_control/parportmodules/.

        However, this code is not yet true "hot plugging", as that a
user level program has to write to
/proc/sys/devices/parport/parportN/deviceid* to cause a device ID to be
reread (and it had better be done when it is safe to do so).  I
understand that there is some standard for IEEE-1284 parallel port
device to tickle to indicate that they have been hotplugged, but I do
not believe that the parport drivers currently detect that, or do
anything with the detection, or if it is even safe to use by default
if arbitrary legacy hardware might be plugged in.

        Finally, on a note that actually has something to do with USB,
I just want to make clear that you can currently read the IEEE-1284
parallel port device ID information with a stock 2.4.3 kernel, under
any of the following scenarios, which cover just about everything:

        o From an ISA or PCI parallel port by reading
          /proc/sys/devices/parport/parportN/autoprobe*, provided that you
          have the parport and parport_pc (or parport_whatever) modules
          loaded, regardless of whether the lp or ppdev modules are loaded
          (lp implements the characters based printer device and ppdev
          is for user level parport drivers that want to drive or read
          each line).

        o Possibly from a uss720 parallel port using the above, since it
          talks to the parport interface, but I am not sure.

        o From a standard USB parallel ("printer") dongle or a "native" USB
          printer when the usb-printer drivers is *not* loaded, via
          
ftp://ftp.yggdrasil.com/pub/dist/device_control/usb-printer-id/usb-printer-id-1.2.tar.gz

        o From a standard USB parallel ("printer") dongle or a "native" USB
          printer when the usb-printer drivers is *is* loaded, via
          _IOR('p', USB IOCN_GET_DEVICE_ID, string_length) ioctl.  I know
          I wrote a little test program for this, but I can't find it at
          the moment.

        By the way, I also posted a patch that deletes the usb_device_id
string field from the usblp data structure, since that information is
always reread from hardware by the ioctl that retrieves the information,
so the stored value is never used.  It just wastes memory.  I think
that patch has fallen through the cracks and I need to resubmit it.
I think everyone liked the patch when I originally posted it, but if
anyone has an objection to it, please let me know.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED]     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to