Hi Kay & Alan Kay Sievers wrote: > 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. > > So this code for switch_logitech was originally authored by Marcel. I can try to help clean this part up, but I'd like to treat that as an independent problem to follow up to after I get the logic for getting this Dell HW working after S3. >>>> 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? > Yes, these are all individual devices. It would be a safe assumption that they have the same parent hub, so perhaps the search could be simplified. > >>> 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. > > I'll look into switching to this pair instead. I didn't see any obvious method to select devices by these properties, but I've just skimmed libusb source looking for them. If I don't find them, i'll resubmit the patch with Marcel's recommendations of using more pointers for readability. -- Mario Limonciello *Dell | Linux Engineering* mario_limonciello@xxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
