Randy / Team: Thanks to all for the help and support. It WAS something obvious I was overlooking - and after toggling the "input core" support to built-in, I was able to build the kernel with the full HID support statically included. EUREKA!
So, now when I boot the new kernel, I see very different (and, I think more favorable ;-) information in syslog: <snip> Dec 18 10:13:31 gw3 kernel: hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s Dec 18 10:13:31 gw3 kernel: hub.c: port 1 connection change Dec 18 10:13:31 gw3 kernel: hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s Dec 18 10:13:31 gw3 kernel: hub.c: port 1, portstatus 301, change 0, 1.5 Mb/s Dec 18 10:13:31 gw3 last message repeated 3 times Dec 18 10:13:31 gw3 kernel: hub.c: port 1, portstatus 303, change 10, 1.5 Mb/s Dec 18 10:13:31 gw3 kernel: hub.c: new USB device 00:02.2-1, assigned address 2 Dec 18 10:13:31 gw3 kernel: usb.c: kmalloc IF dde75600, numif 1 Dec 18 10:13:31 gw3 kernel: usb.c: skipped 1 class/vendor specific interface descriptors Dec 18 10:13:31 gw3 kernel: usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 Dec 18 10:13:31 gw3 kernel: usb.c: USB device number 2 default language ID 0x409 Dec 18 10:13:31 gw3 kernel: Manufacturer: TRIPP LITE Dec 18 10:13:31 gw3 kernel: Product: TRIPP LITE OMNIVS1000 Dec 18 10:13:31 gw3 kernel: hiddev0: USB HID v1.00 Device [TRIPP LITE TRIPP LITE OMNIVS1000 ] on usb1:2.0 Dec 18 10:13:31 gw3 kernel: usb.c: hid driver claimed interface dde75600 Dec 18 10:13:31 gw3 kernel: hub.c: port 2, portstatus 100, change 0, 12 Mb/s Dec 18 10:13:31 gw3 kernel: hub.c: port 3, portstatus 100, change 0, 12 Mb/s </snip> So, this looks WAY better, right? Now I see the device is being "claimed" by the HID driver, and even being assigned a device file (/dev/usb/hid/hiddev0). This is all excellent... but alas, it STILL doesn't work. Perhaps now it's just an application thing - but neither NUTS (using either of the TRIPPLITE drivers) nor the vendor-provided PowerAlert software can detect the UPS when pointing to that device file. ARGH! I'm closer still - but no cigar. I'm wondering if it's a problem with these lines, where the interface is defined: Dec 18 10:13:31 gw3 kernel: usb.c: kmalloc IF dde75600, numif 1 Dec 18 10:13:31 gw3 kernel: usb.c: skipped 1 class/vendor specific interface descriptors That "skipped 1 class/vendor specific interface desriptors" doesn't sound good. I'm wondering if at this point, I need some device-specific driver, or at least configuration information, which might be written to some configuration file? Honestly, I thought that layer of functionality was provided by the various apps (NUTS, or PowerAlert) - but the drivers they provide still seem unable to communicate with the UPS via that interface. Again, I'd like to thank Randy and others who have already helped a great deal - as well anyone else who might have some insight into this pesky problem! Have a great day, Billy On Thu, 18 Dec 2003, Randy.Dunlap wrote: > On Wed, 17 Dec 2003 20:59:57 -0800 (PST) Billy Glenn <[EMAIL PROTECTED]> wrote: > > In the future, please continue such questions on the mailing list. > That will be more helpful to everyone who might have similar questions, > and it could also get you a quicker answer. > > I am using 2.4.23. I think that you are also.... > > > | Thanks MUCH for the prompt response! When you say "input core" - does > | that correspond to the option "HID input layer support"? If so - I do > | have this set to built-in, as well. Under the: > | > | --- USB Human Interface Devices (HID) section in "make menuconfig" > | > | <*> USB Human Interface Device (full HID) support > | [*] HID input layer support > | [*] /dev/hiddev raw HID device support > > No, I'm referring to something that is outside of the USB config > parameters. Like here: > > Old CD-ROM drivers (not SCSI, not IDE) ---> > ** Input core support ---> > Character devices ---> > Multimedia devices ---> > File systems ---> > Console drivers ---> > Sound ---> > USB support ---> > > > | I'll poke around and see if I can find "input core" somewhere else - but > | if it's relative to HID, I'm guessing it's the one above. In that case - > | any thoughts on why it wouldn't find input_event? I'm not ashamed to > | admit that the intricacies of modules, dependancies, and symbols is at the > | fringe of my comprehension. I certainly appreciate your help! > | > | Looking in drivers/usb within the source tree, grep turns up references to > | input_event in several different source files, most notably hid-input.c. > | Thought I might have some stale files around from the number of times I've > | compiled, so saved off my config and did the whole "make mrproper" deal to > | ensure a clean slate. No luck, no matter what I try. It just won't > | compile when I select built-in for the "USB Human Interface Device (full > | HID) support" code. > > HID is a user of the generic input core. Enabling Input Core support > should fix this for you. > > -- > ~Randy > ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
