On Fri, Nov 02, 2007 at 09:54:50AM -0400, Martin Owens wrote: > Hey all, > > I don't know how many of you keep up with Conduit and OpenSync mailing > lists but recently there was an explosion of talk about how to better > integrate things.
Thanks for the heads-up. I took a while today to catchup on that thread. I hadn't heard of Conduit before. This "just working" is one of those elusive features that everyone wants and few are willing to wait for. I like the careful architecture work going into OpenSync, and hope it's not lost for mainstream use, as the world rushes toward sync in their own ways. :-) > So my phone is a Blackberry Pearl, I'm going to be attempting to make > the callbacks from HAL which populate HAL with more information about > the phones, this is then used by opensync or what ever sync program to > know all configuration options of unique id's for the phone. > > Then comes the fun part of intergrating blackberry-opensync plugin > with new version of opensync _and_ making it all "just work" when you > plug in the phone. > > Information on how I can ask the phone if it is a pearl or one of the > other blackberries would be good too and the hope is that this > callback would stick the phone in the right mode or continue to let > bcharge do it depending. Take a look at the latest "btool -l" output, which displays the PIN number, and the device description as returned via the protocol. [EMAIL PROTECTED] src]$ btool -l Blackberry devices found: Device ID: 0x80a2b28. PIN: 3009efe3, Description: RIM 7700 Series Colour CDMA Handheld This is available by using the Probe class only, which is fairly simple. Note that the Probe class is designed to search for all Blackberry devices attached via USB and return them all. In HAL's case, I assume this isn't totally desired. Probe uses libusb, so this may be a challenge, as libusb is cross platform, and focuses on the data available via USB only. Any system-specific identifiers (like sysfs paths) are well hidden under the API. What information does HAL provide to a callout? For Pearl detection, the Product ID is still the best bet if all you have is the USB info. ID's 6 and 4 are Pearl/Curve devices, and ID 1 is Blackberry Classic. Bcharge runs very quickly on plugin. If you're going to use a callout to probe the device for the description string, just wait a few seconds, and bcharge will be done. You will need to wait anyway, as the device resets itself, and will look like it was just plugged in again. Keep in mind that some systems may use the berry_charge kernel module, which behaves similar to bcharge, and will cause the device to reset as well. I don't think you can avoid the wait period. As for porting to OpenSync 0.3x, there is the quick and dirty way, and the better way. My plan for 0.3x is to use the OpenSync XML formats for all data parsing and generation, as well as use OpenSync timezone handling code (I haven't looked recently, but I assume that code isn't finished yet either). The quick and dirty way would be just changing the functions to match the new API and keep using Barry's vformat.c code to do the parsing. If you're in a hurry, this can be done too. Most seem to be in a hurry. :-) I'd consider patches for either method. Mail the list if you start any serious work on the plugin, so we don't duplicate effort. Let me know if you need more info, or even API changes in the Barry library. - Chris ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
