Re: [PARPORT] autoloading drivers based on ieee1284 device ID changes?

From: Tim Waugh (
Date: Tue Dec 12 2000 - 08:27:57 EST

  • Next message: MURAT BAYRAKCI (IT-TPL-ANK): "[PARPORT] RE: SUMMARY: long file names while recording"

    On Mon, Dec 11, 2000 at 05:23:24PM -0800, Adam J. Richter wrote:

    > If so, I am wondering if it would be useful to have some kind of
    > /sbin/hotplug support for this, since I understand there is supposed
    > to be a way that these devices can signal that something has changed
    > (hopefully this includes things like that they have been plugged
    > in).

    You can't get this kind of information reliably, AFAIK.

    The devices which do reveal IEEE 1284 device IDs (most devices made
    since about 1997 I think) mostly do so in various not-quite-compliant
    ways. We work around the common bugs in parport_probe; I don't think
    the USB people do, but perhaps all the USB devices do it right.

    But you don't get so much as an interrupt necessarily when you plug in
    (for example) a ZIP drive.

    Plus, the parallel port isn't really a hot-plug thing, although most
    vendor's parallel ports will prevent themselves from blowing up if you
    do use them that way.

    > That way, if you plugged in a zip disk, the module could
    > be automatically loaded and other actions could also be taken, even
    > things like mounting it if there is media present.

    This would be nice.

    > Currently, the standard USB parallel port driver supports
    > an ioctl for extracting this information,

    The non-USB parallel port driver exports this via /proc, although
    unfortunately it munges the information so you don't get exactly what
    the device said.

    > and there is a user level utility from Michael Fulbright at Red Hat
    > that works with the standard parallel ports by manipulating IO ports
    > directly (!),

    Yeah, me too (deviceid).

    > through the existing mechanisms or, ideally, a uniform
    > ioctl for downloading the ID information, and then have it
    > modprobe the appropriate module based on that information.

    Yes, this would be nice. Randy Dunlap and I talked about this some
    time ago, but nothing happened.

    > Any comments on this idea would be appreciated. If it
    > seems feasible, I will probably take a whack at implementing
    > it.



    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Tue Dec 12 2000 - 08:29:06 EST