On Thu, Jul 16, 2009 at 00:24, Mario Limonciello<mario_limonciello@xxxxxxxx> wrote: >> 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. Sure, it still needs to be fixed or ripped out before the next udev release. We can not keep stuff like this in the udev tree. People use this as a starting point for their new tools, and therefore we can not ship such broken things. >>> 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. Fine, just put all that in a function that accepts bus and dev num as a parameter to find the device. If libusb can not be fixed, I'll put the needed bits in the udev tree and drop libusb completely. As said, we are not going to search over all devices to find what we already have. 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
