Hi Alan: Alan Stern wrote: > 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. > Yeah, Kay already identified why the rule wasn't being executed. It was reliant on properties of the device that aren't cached in the udev database. > 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. > I wasn't sure I wanted to jump to this conclusion as I can't predict if this will change for future hardware that supports these features. > Alan Stern > > I'm at a loss at what else can really be done from userspace. If I can't match the device on removal and send it to the userspace app, not sure how else it can be revived. -- Mario Limonciello *Dell | Linux Engineering* mario_limonciello@xxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
