On Wed, Jul 15, 2009 at 04:07, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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! Right, and even when it's loaded, there is no guarantee, that this device is already created by udev. >> > 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. Yeah, what a hardware. :) These are all *devices* not *interfaces* right? And we poke a sibling device which is a HID device to manage the other sibling which shows up as the bluetooth device then? >> 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. Yeah, that would be good to use. That's what the device nodes use too. > 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. I didn't see anything like that. If that can't be done, I'll just add the few needed things to switch the device to code inside of udev and drop that libusb thing entirely. Thanks, 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
