Error 'USBDeviceOpen failed' only with my user account when using PowerMate USB Controller. OK with fresh account

Question

I have a PowerMate USB controller from Griffin: it works, but using my normal user account I can't control the light settings. With a fresh new account, everything works as expected. How can I find what cause the trouble?

I can interact with it, turn it, press it, and it reacts as expected.
But I can't control the light settings: the light is always on, even if I set it to pulsing mode. It doesn't blink when it should.

Each time I do an action that should change the light state (assigning the Default Set to the PowerMate unit, or changing the default light state in the settings), I get this error in the console:

19/03/11 17:39:42 PowerMate[441] PowerMate Device location: 26410000 service: 0000b69b USBDeviceOpen failed: e00002c5

Sometimes, I get multiple entries of the same error (up to 14 times). Except for this error and the following error at launch of the app, there is nothing helpful.

Path (null) given to -[NSWorkspace iconForFile:] is not a full path.

---

I'm running Lion 10.7.1 (problem was similar on Snow Leopard).

Here is what I have done so far to troubleshoot:

• Make sure the application PowerMate.app is not running

• Un-plug the USB PowerMate device and every other USB devices (except for my keyboard)

• Remove everything created by the application PowerMate.app with:

.

rm ~/Library/Preferences/com.griffintechnology.PowerMate.plist;
rm -rf ~/Library/Caches/com.griffintechnology.PowerMate;
rm -rf ~/Library/Application\ Support/PowerMate;

• Repair the authorization with Disk Utility.app

• Reboot.

• Apply the latest combo update (MacOSXUpdCombo10.6.6.dmg)

• Reboot

• Launch the latest version of the PowerMate.app application (version 3.0 - 3012).

• Then plug-in the USB PowerMate device.

Anything else you suggest to find the difference between my account and a new one?

Known Differences That Matter between the accounts:

Similarities between the accounts:

Both accounts are admin of the machine.
They are members of the same group.

Output of the id command: my normal account (the one with the issue):
uid=501(mylogin) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),102(com.apple.access_ssh),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),402(com.apple.sharepoint.group.1)

the fresh new test account (the one where it works):
uid=502(test2) gid=20(staff) groups=20(staff),401(com.apple.access_screensharing),204(_developer),100(_lpoperator),98(_lpadmin),81(_appserveradm),80(admin),79(_appserverusr),61(localaccounts),12(everyone),402(com.apple.sharepoint.group.1)

I am in contact with Griffin support. They are very nice, but so far we haven't been able to find the reason of the issue.

---

Update: Apparently, the error code e00002c5 means "exclusive access and device already open".
Any idea how to figure what process has access to a USB Device?

Answer 1

This sounds like something is broken with the device node for the usb device. You an compare the settings with something like this:

1. figure out what the device node is. The last step will output the device name following a > (and some other junk you can ignore.) You'll need that device name in step 2. It would be best to do this test on the temp user that works, just after a fresh reboot.
   1. ls -1 /dev/ > /tmp/before (note, that's "dash one")
   2. plug the device in
   3. ls -1 /dev/ > /tmp/after
   4. diff /tmp/before /tmp/after
2. compare the device permissions between the two.
   1. login as yourself
   2. ls -el /dev/devicename > /tmp/broken (note, that's "dash e ell" this time)
   3. login as the temp user
   4. ls -el /dev/devicename > /tmp/working

This last bit will create two files that look something like this:

crw-rw-rw- 1 root wheel 11, 1 Mar 26 16:20 cu.Bluetooth-PDA-Sync

The first bit (crw-rw-rw-) is a textual representation of the mode bits... it's possible a difference there is the cause.

The next bit that might be the problem is the user (root) and group (wheel), either of which could be causing the problem.

I'm assuming it's being dynamically created (incorrectly) when the device is inserted. Another possibility is that the device node is persistent, but wrong. If both of those files MATCH, then show us what they are and we can probably figure out what the device should be set to.

Answer 2

I found the culprit: MenuMeters was accessing the light setting of the PowerMate device.

I didn't know MenuMeters had a setting to show the CPU usage via the PowerMate glow. It was there since 2003, but I didn't care about it since I didn't own a PowerMate before.

The latest version fix this bug. Many thanks to Alex Harper for his great piece of software and continuous support. http://www.ragingmenace.com/software/menumeters/history.html