On Tue, 14 Jul 2009, Mario Limonciello wrote: > 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. For now you should worry more about getting it to work. Later on you can worry about future hardware changes. > > 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. You can relax the matching criterion for the removal rule. At the time the device was created, you can store all the information you will need to create it again -- including any matching info which isn't present at removal time. Can you post examples of the creation and removal udev events? Then I'll be able to see exactly what information is present. 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
