Nope.. it isn't 3 lines... see below ----- Original Message ----- From: "David Brownell" <[EMAIL PROTECTED]> To: "Ken Hahn" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>
> > > The defined method involves providing a script in /etc/hotplug/usb/... > > > invoking "fxload" with the right firmware for the particular device IDs. > > > http://linux-hotplug.sourceforge.net/?selected=usb describes it > > > (at the end of the page). > > > > > I did that. Added to usb.handmap the lines: > > bpide6 0x0003 0x0ac9 0x1003 0x0000 0x0000 > > 0x00 0x00 0x00 0x00 0x00 > > 0x00 0x00000000 > > bpckusb 0x0003 0x0ac9 0x0000 0x0000 0x0000 > > 0x00 0x00 0x00 0x00 0x00 > > 0x00 0x00000000 > > ... > > Two comments ... > > First, it looks like you've added three lines for each type of firmware. > That won't work correctly, the "modules.usbmap" format is one line > per "usb_device_id". I could believe that the failures you're seeing > are because you're using more than one line per entry ... it's sure > acting as if it thought "0x0" was a module name! Ya know, I checked it in pico (pico -w), it's one line, not three.. here.. let me find the source of that error (the 3 lines is cause of wrapping on the e-mail program here) Nope, I just took out the lines I added to usb-handmap.. let me re-install the hotplug rpm. Ok.. I isolated what it is! First off.. I'm using the latest rpm on the site: hotplug-core-2001_09_19-1.i386.rpm hotplug-utils-2001_09_19-1.i386.rpm Attempting to insert the 0x00 module happens when there is an extra BLANK line on the end of the file. Sounds like an awk problem to me (haven't checked the scripts yet) Now the error dump looks like this: Dec 19 12:59:31 marvin kernel: hub.c: USB new device connect on bus1/1, assigned device number 6 Dec 19 12:59:31 marvin kernel: usb.c: USB device 6 (vend/prod 0xac9/0x0) is not claimed by any active driver. Dec 19 12:59:33 marvin /etc/hotplug/usb.agent: Modprobe and setup bpckusb for USB product ac9/0/0 Dec 19 12:59:33 marvin modprobe: modprobe: Can't locate module bpckusb Dec 19 12:59:33 marvin /etc/hotplug/usb.agent: ... can't load module bpckusb Here's definately an attempt to load a bpckusb module, which of course dosen't exist it's only a firmware loading script! That find in the if statement is wrong! Look at the find man page! (like I wrote in my first e-mail) > > Second, it'd probably be simpler to have one script "backpack" > that switches on vendor/product. Here's what one script I use > does, you could modify it: I'll probably do that when I get this working... (as I say, I've had it working with my kludged script (which dosen't use elif, simply always checking for a script, wheather a module inserted or not). But this still dosen't explain why jphoto works and this dosen't Skipping lower: > > Is that actually an issue for this device though? Did you verify? > What are your symptoms? > Good question.. my test machine dosen't have APM. So no symptoms, just speculation. Our CD-RW drives will probably be fine, but if somebody did swap on a BACKPACK hard drive.. it could be a problem (by oliver's reasoning). > > In addition, there is no central package of firmware, so do I > > make our own firmware RPM/deb? No good answer on the linux-hotplug list. > > I don't remember seeing the question. For GPL'd firmware, I can > imagine a package associated with the hotplug scripts. If it's not > GPL'd, it'd seem that some other RPM/deb distribution would be > appropriate. Already got permission to gpl... Probably need to doublecheck that, but I don't think it'll be a problem >> firmware should have a separate mechanism from > > notifying/launching applications to use a device) > > Separate discussion, which should be on the hotplug list if you > want to pursue it. I'd call that a policy versus mechanism issue. > The same mechanism _ought_ to support many policies, and > IMO "load firmware" is as much a policy as "modprobe" or "start > application Z". > > The tricky part is policies that involve interacting with a user or > administrator -- "what desktop?" Hotplug is set up to be a system > mechanism that doesn't interact. It needs some standard hook > to send notificatiosn to tools on some desktop (local, remote, etc). Agreed... I'll mention it over there later (although that list appears somewhat dead), just while I'm replying I'd mention that the difference in mechanism is that you may want application notification to depend on a module insertion, but not have firmware loading depend on a module insertion Still don't know how to solve my problem Thanks for trying (get this licked yet), -Ken Hahn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
