On Mon, Jun 01, 2009 at 10:47:59PM +0000, freeslkr wrote:
> The only rule that matches my device is:
> 
> BUS=="usb", ENV{DEVTYPE}=="usb_device", ACTION=="add", SYSFS{idVendor}
> =="0fca", SYSFS{idProduct}=="8004"
> 
> This doesn't create the symlink bb-%k, so 10-blackberry.perms does not 
> cause the device owner to be set to the console user. Is this intentional 
> and why?

Yes, that is intentional.  When bcharge is run, some of the Pearl devices
change their product IDs.  Normally they end up with product ID 0004.
So the above rule is meant to see the freshly plugged device, run bcharge,
and then the other rules are meant to see the new Product ID, which
the device will live with for a while, and only set the symlinks at
that point.

No need to set symlinks for a device that is only visible for maybe a few
milliseconds.


> When I change the 10-blackberry.rules line to:
> 
> BUS=="usb", ENV{DEVTYPE}=="usb_device", ACTION=="add", SYSFS{idVendor}
> =="0fca", SYSFS{idProduct}=="8004", SYMLINK+="bb-%k"
> 
> then /dev/bus/usb/001/005 is owned by the console user and he can run 
> bidentify and btool, as expected. Another question I have is: should the 
> usb endpoint devices /dev/usbdev1.5_epXX be owned by the console user 
> (currently they aren't)?

It depends on what libusb needs, in order to talk to the device.
I don't believe /dev/usbdev* is used by libusb at all, so no need to
worry about them.


> Because I did not have bcharge run, I expected that the blackberry would 
> not charge when I plugged it in; however, it _does_ charge. Note that 
> berry_charge.ko is in /lib/modules, but it does not load. Is this 
> expected, in which case what are the purposes of bcharge and 
> berry_charge.ko?

I'm guessing that the berry_charge kernel module doesn't recognize
your 8004 Product ID.  The kernel module lags behind bcharge.

*checks kernel sources*   Yes, that's the case.

In ideal circumstances, you could choose whether to use bcharge or
berry_charge, and either would reset your device to use 500mA, and
the Product ID would change to something like 0001 or 0004.

In practice, though, bcharge usually does a better job (in my opinion),
and you have to make sure only one runs at a time.

- Chris


------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel

Reply via email to