On Wed, 15 Jul 2009, Kay Sievers wrote: > > 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. That's absolutely right. At the time the USB device event takes place, the HID driver might not even be loaded yet! > > Why do you need to *find* the device at all? Same question for the > > normal call case too, not only the resume case. This is the difficult aspect of the application. The program needs to poke at an HID device when it receives an event concerning an HCI device. Mario doesn't want to assume there will be any fixed relation between the two devices (although it should be safe to assume they will always have the same parent hub). Thus some sort of search appears to be necessary. It's not clear whether the search result can be saved (say in udev's database) so that later "resuscitate" invocations don't need to repeat the search. > 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. The unique identifier appropriate for libusb is a (bus number, device number) pair. These values will not change across a suspend/resume. I don't know whether libusb has an API to open the particular device given by those numbers, but it ought to. Alan Stern -- 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
