On Thu, 9 Jul 2009, Mario Limonciello wrote: > Hi Alan: > > Alan Stern wrote: > > It's hard to tell exactly what's going on from Mario's description. > > IIUC, after resume the system knows that the HCI device is gone. It's > > the HID devices that are in the same state as before. > > > > A dmesg log including boot and a suspend-resume cycle, from a kernel > > with CONFIG_USB_DEBUG enabled, would help clarify the situation. > > > > Alan Stern > > > > > Sorry for the delay, had some hardware failures. Here's a dmesg log > with CONFIG_USB_DEBUG turned on and a suspend-resume cycle. Right. The log clearly shows that HID devices 4-1.1 and 4-1.2 survive the suspend-resume cycle intact, whereas the BT device 4-1.3 is gone. Since the BT device was created by means of a userspace script in the first place, it seems logical that a userspace script should respond to the uevent announcing its disappearance and try to bring it back to life. Last I heard, you had created a udev rule which was supposed to match the removal event for the BT device, but which udev wasn't executing. Is that still the case? If it is, you should post the rule together with the udev log for a resume. Maybe somebody will be able to figure out why the rule isn't being executed. Also, I noticed that your C program for reviving the BT device seemed more complex than necessary. You should know beforehand that if the BT device's path is 4-1.3 then the corresponding mouse device's path will be 4-1.2 (just decrement the last byte of the pathname). You can then match this device up with libusb by reading the busnum and devnum attributes from the sysfs directory. 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
