Thread: [Barry-devel] Charging the BlackBerry on Linux
Status: Beta
Brought to you by:
ndprojects
Menu
▾
▴
barry-devel
|
From: Chris F. <cd...@fo...> - 2006-12-29 22:21:02
|
Hello Barry fans! Just released today is a new standalone utility: bcharge. It uses libusb to scan your USB bus for BlackBerry handhelds, and boosts the power to 500mA if isn't that high already. You can download the single source file, or an RPM for this utility, in the Barry download area: http://sourceforge.net/projects/barry Compiling the source file is pretty easy if you have the stable libusb library installed: g++ -o bcharge bcharge.cc -lusb The RPM attempts to get fancy and adjust your udev rules so that it automatically runs bcharge as soon as you plug in your BlackBerry. The RPM was made on a recent version of Fedora. As usual, please report any problems you have to the list. This is a New Years gift that I want to have working for everyone. :-) Happy New Year! - Chris P.S. For those interested in what was needed to get this to work: You'll notice that bcharge.cc is pretty small. The two USB control messages are pretty non-standard, and did not show up in any capture I did, either on Windows with USBSnoop, or on Linux, using 2.6.18 with usbfs_snoop and VMWare. Turned out that one of the code paths for logging control URBs in the kernel when using usbfs_snoop was missing the full logging code. You can patch your kernel with the following patch, or wait for the next kernel release, which should have this fixed. http://marc.theaimsgroup.com/?l=linux-kernel&m=116625529726498&w=2 With that patch, you can see the full proprietary USB conversation using VMWare. I've added some notes on doing USB captures, which you can find in Barry's CVS tree: http://barry.cvs.sourceforge.net/barry/barry/doc/USB-capture.txt?revision=1.1&view=markup |
|
From: R P H. <he...@ow...> - 2006-12-29 23:58:03
|
On Fri, 29 Dec 2006, Chris Frey wrote:
> Hello Barry fans!
>
> Just released today is a new standalone utility: bcharge.
>
> It uses libusb to scan your USB bus for BlackBerry handhelds, and boosts
> the power to 500mA if isn't that high already.
yayyy -- To this point, I have had to keep a Windows box
about, for chargeing, for pulling a sync off of the
contacts, and for the periodic backup of the unit; updating
the binaries is out there as a use case well.
one down -- yayy!!
> g++ -o bcharge bcharge.cc -lusb
>
> The RPM attempts to get fancy and adjust your udev rules so that it
> automatically runs bcharge as soon as you plug in your BlackBerry.
> The RPM was made on a recent version of Fedora.
um -- no .spec file or Source RPM was posted -- running the
rpm requires a leap of faith -- might we see the contents
please?
In running the binary (compiled from the sources [under
CentOS-4, without issue, as one would expect] I could examine,
it scans, and does not find a device, and so exits, when the
Blackberry is not already plugged in.
RFE: I understand this is a first pass on this code, but
adding a sleep and repoll, or even a (unplug|plug) event
driven requery would be useful.
After starting the binary, with the device already plugged
in, I get the customary message from the device about low
current level problems; Is there a way for the program
to query, and then report back, once it has made then change?
lsusb reports for my device [an 8700] (after the program has
run and exited):
Bus 003 Device 005: ID 0fca:0001 Research In Motion, Ltd.
Blackberry Handheld
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 16
idVendor 0x0fca Research In Motion, Ltd.
idProduct 0x0001 Blackberry Handheld
bcdDevice 1.04
iManufacturer 1 Research In Motion
iProduct 2 BlackBerry Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Thanks again
- Russ Herrold
|
|
From: Chris F. <cd...@fo...> - 2006-12-30 00:17:33
|
On Fri, Dec 29, 2006 at 06:28:13PM -0500, R P Herrold wrote: > > g++ -o bcharge bcharge.cc -lusb > > > > The RPM attempts to get fancy and adjust your udev rules so that it > > automatically runs bcharge as soon as you plug in your BlackBerry. > > The RPM was made on a recent version of Fedora. > > um -- no .spec file or Source RPM was posted -- running the > rpm requires a leap of faith -- might we see the contents > please? You can snag the src rpm from here: http://www.netdirect.ca/downloads/barry/ I'll update the SourceForge page with it as well. > In running the binary (compiled from the sources [under > CentOS-4, without issue, as one would expect] I could examine, > it scans, and does not find a device, and so exits, when the > Blackberry is not already plugged in. > > RFE: I understand this is a first pass on this code, but > adding a sleep and repoll, or even a (unplug|plug) event > driven requery would be useful. The idea is to use the hotplug or udev features to run bcharge on these events. These events are already handled, so might as well do it in a system-consistent manner. It helps keep the bcharge.cc code short and concise too. :-) > After starting the binary, with the device already plugged > in, I get the customary message from the device about low > current level problems; Is there a way for the program > to query, and then report back, once it has made then change? This is what you should see when you run bcharge: [cdfrey@tools]$ g++ -o bcharge bcharge.cc -lusb [cdfrey@tools]$ ./bcharge Scanning for Blackberry devices... Found...attempting to adjust charge setting. 1 device adjusted. [cdfrey@tools]$ ./bcharge Scanning for Blackberry devices... Found...already at 500mA 0 device adjusted. If you run it twice, it should say it found it, and do nothing. > lsusb reports for my device [an 8700] (after the program has > run and exited): > > Bus 003 Device 005: ID 0fca:0001 Research In Motion, Ltd. > Blackberry Handheld > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 16 > idVendor 0x0fca Research In Motion, Ltd. > idProduct 0x0001 Blackberry Handheld > bcdDevice 1.04 > iManufacturer 1 Research In Motion > iProduct 2 BlackBerry Device > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 46 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > MaxPower 500mA ^^^^^^^^ That's the key value :-) - Chris |
|
From: Rick S. <rw...@al...> - 2006-12-30 17:09:58
|
Great news! So much for my plans for the day :( I think it is even simpler than that though. The first control message is getting info from the device but not using it. I think the same thing can be accomplished with only the second control message. Seems to work for me at least .... It would be nice if this could be done without the usb resetting :( Oh well .... On Fri, 2006-12-29 at 17:20 -0500, Chris Frey wrote: > Hello Barry fans! > > Just released today is a new standalone utility: bcharge. > > It uses libusb to scan your USB bus for BlackBerry handhelds, and boosts > the power to 500mA if isn't that high already. > > You can download the single source file, or an RPM for this utility, > in the Barry download area: > > http://sourceforge.net/projects/barry > > Compiling the source file is pretty easy if you have the stable libusb > library installed: > > g++ -o bcharge bcharge.cc -lusb > > The RPM attempts to get fancy and adjust your udev rules so that it > automatically runs bcharge as soon as you plug in your BlackBerry. > The RPM was made on a recent version of Fedora. > > As usual, please report any problems you have to the list. This is > a New Years gift that I want to have working for everyone. :-) > > Happy New Year! > > - Chris > > > > > > > P.S. For those interested in what was needed to get this to work: > > You'll notice that bcharge.cc is pretty small. The two USB control > messages are pretty non-standard, and did not show up in any capture > I did, either on Windows with USBSnoop, or on Linux, using 2.6.18 > with usbfs_snoop and VMWare. > > Turned out that one of the code paths for logging control URBs in the > kernel when using usbfs_snoop was missing the full logging code. > You can patch your kernel with the following patch, or wait for the next > kernel release, which should have this fixed. > > http://marc.theaimsgroup.com/?l=linux-kernel&m=116625529726498&w=2 > > With that patch, you can see the full proprietary USB conversation using VMWare. > > I've added some notes on doing USB captures, which you can find in > Barry's CVS tree: > > http://barry.cvs.sourceforge.net/barry/barry/doc/USB-capture.txt?revision=1.1&view=markup > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Barry-devel mailing list > Bar...@li... > https://lists.sourceforge.net/lists/listinfo/barry-devel |
|
From: Chris F. <cd...@fo...> - 2006-12-30 17:35:35
|
On Sat, Dec 30, 2006 at 11:42:57AM -0500, Rick Scott wrote: > Great news! So much for my plans for the day :( > > I think it is even simpler than that though. The first control message > is getting info from the device but not using it. I think the same thing > can be accomplished with only the second control message. Seems to work > for me at least .... It would be nice if this could be done without the > usb resetting :( Oh well .... Cool, I'll have to try it with just the single message. I believe the reset is mandatory though, otherwise the USB host won't realize there has been a change in the device's configuration descriptor, and that's the only way the device can ask for more power, since USB is host-driven. Do you have any analysis of what data is returned from the first message? I'd like to document that if someone knows what it means. :-) Thanks, - Chris |
|
From: Rick S. <rw...@al...> - 2006-12-31 10:43:51
|
On Sat, 2006-12-30 at 12:35 -0500, Chris Frey wrote: > On Sat, Dec 30, 2006 at 11:42:57AM -0500, Rick Scott wrote: > > Great news! So much for my plans for the day :( > > > > I think it is even simpler than that though. The first control message > > is getting info from the device but not using it. I think the same thing > > can be accomplished with only the second control message. Seems to work > > for me at least .... It would be nice if this could be done without the > > usb resetting :( Oh well .... > > Cool, I'll have to try it with just the single message. > > I believe the reset is mandatory though, otherwise the USB host won't > realize there has been a change in the device's configuration descriptor, > and that's the only way the device can ask for more power, since USB > is host-driven. > > Do you have any analysis of what data is returned from the first message? > I'd like to document that if someone knows what it means. :-) It is 2 bytes, 01 00. It is the same with my 8700 and 6200. I was hoping that it would indicate if the device needed more power. If you do this with the 6200 you get a protocol error from the set_configuration. > > Thanks, > - Chris > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Xmblackberry-devel mailing list > Xmb...@li... > https://lists.sourceforge.net/lists/listinfo/xmblackberry-devel |
|
From: Chris F. <cd...@fo...> - 2007-01-04 22:07:23
|
For those of you using Ubuntu, it appears that it includes a newer version udev than Debian stable, which I was using to make the package. I've updated the deb package to detect this and adjust for it. If anyone used the deb package and couldn't get the automatic stuff working, please give barry_0.1-2_i386.deb a try and let me know if you have any problems. It's available on the SourceForge file download page. - Chris |
Thanks for helping keep SourceForge clean.
X