8

I am trying to make a script (on linux) that can turn a light in my mouse on or off.

This is the code I have so far:

import usb.core
import usb.util
import sys
interface = 0
dev = usb.core.find(idVendor=0x1532, idProduct=0x0017)

def main():

        if dev is None:
            print "device not found"

        else:
        print "device found"
        if dev.is_kernel_driver_active(interface) is True:
            print "but we need to detach kernel driver"
            dev.detach_kernel_driver(interface)
            print "claiming device"
            usb.util.claim_interface(dev, interface)


            print "release claimed interface"
            usb.util.release_interface(dev, interface)
            print "now attaching the kernel driver again"
            dev.attach_kernel_driver(interface)
            print "all done"
return 0

if __name__ == '__main__':
    main()

This works fine but if I try to do a: dev.set_configuration()

after the claim_interface(dev, interface)

the script returns the error: usb.core.USBError: Resource busy

Why is it still busy after I have detached its kernel driver?

Paolo Casciello
  • 7,982
  • 1
  • 43
  • 42
Jim
  • 995
  • 2
  • 11
  • 28

2 Answers2

7

Not sure if this will solve, but are the udev rules for your mouse being set up correctly? I had a similar problem with a custom device a friend did for me and I solved by adding a rule like:

SUBSYSTEM !="usb_device", ACTION !="add", GOTO="device_rules_end"
SYSFS{idVendor} =="1532", SYSFS{idProduct} =="0017", SYMLINK+="mydevice"
MODE="0666", OWNER="<your-username-here>", GROUP="root"
LABEL="device_rules_end"

in my /etc/udev/rules.d folder.

HTH!

EDIT: Before adding the rule, try running your script with sudo. If it will work that way it's almost certainly a permission setting that will be fixed by the above rule.

mac
  • 42,153
  • 26
  • 121
  • 131
  • I still get "usb.core.USBError: Resource busy" when running this as root and with the rule added. But your answer makes me able to run the script as a normal user :) – Jim Nov 22 '11 at 10:47
  • @IronMonkey - Yes. That's the idea of the rule: assigning control of the device to you! :) If this answer was useful to you don't forget to upvote and eventually accept it if it solves the issue for good. – mac Nov 22 '11 at 11:29
4

I had this problem too. Your code works well if you "set_configuration" first and only then claim the interface. This is also the order suggested here: http://libusb.sourceforge.net/api-1.0/caveats.html

Jaap Versteegh
  • 761
  • 7
  • 15
  • Having the exact same issue, this resolves the problem for me. Quoting from the link in the answer: _The above method [set config, then claim interface] works because once an interface is claimed, no application or driver is able to select another configuration._ This also explains why the error is thrown: the original code claimed the device, thereby locking its configuration. – jro Jun 08 '12 at 08:31