On Tue, Jul 14, 2009 at 18:40, Mario
Limonciello<mario_limonciello@xxxxxxxx> wrote:
>> 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.
Right, sysfs is gone when the remove event is handled. And stuffing
all sysfs properties in the udev database would just be totally
insane. :)
>> 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.
What the action you want to take at removal? You can set
ENV{REMOVE_CMD}= and it will be passed to RUN+= for that exact device
when it goes away.
You can also just store any other custom property in the udev
database, and it will be there on remove.
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
