On Tue, Jul 14, 2009 at 23:24, Kay Sievers<kay.sievers@xxxxxxxx> wrote: > On Tue, Jul 14, 2009 at 23:00, Mario > Limonciello<mario_limonciello@xxxxxxxx> wrote: > > Ok, I took a look first over the stuff we currently have. > > What kind of directory is that? I've never seen such a thing: > sprintf(devname, "%s/usb/hid/hiddev%d", devpath, i); That all needs to be fixed. We are not hooking into USB device events and write to hard-coded /dev/hidraw* devices. If these devices need to be handled with hidraw, the tools needs to hook into hidraw events. >> I'll split that up into some more readable for loops. I was >> just trying to walk through the bus to find the appropriate usb_device to >> match and return. > > Why do you need to *find* the device at all? Same question for the > normal call case too, not only the resume case. Seems libusb is too stupid to handle a specific device, and unfortunately even the new libusb seems to be not better regarding this. It really needs an interface to select a specific device by whatever _unique_ property, not by vid/pid, instead of this braindead brute-force searching across all possible devices to find itself. So, seems there is not hid2hci fault, and it can not do much here. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
