I've been quiet on this so far, but good things don't last forever :) Greg has, or will, submit the power change part for the inclusion in the kernel, so bcharge may become a non-issue. With a bit of luck, the whole driver may become a non-issue (fingers crossed, not holding my breathe). The power setting can be matched against, with bMaxPower=="100mA" in the udev.rules, with FC4 and above. I think the other issues can be determined with bcdDevice. I know that the 6200's won't go past 100mA, so all recent attempts end up in an endless loop trying to set 500mA. The issue is always going to be, sometimes I want Desktop, sometimes I'm gonna want usb_storage. Not loading usb_storage is NOT going to be a solution.
I had my hands on an 8800 for a while today, before the owner came back from lunch :), so I worked through part of this. The CVS version of bcharge kept saying it wasn't a pearl, so there is still some work to be done :( I was thinking that the bcdDevice was the key. I did manage a complete backup of the databases though .... On Thu, 2007-03-22 at 10:31 -0700, troy engel wrote: > On 3/21/07, Chris Frey <[EMAIL PROTECTED]> wrote: > > Thanks. Looks like I can't use iProduct as a way to determine whether > > I'm talking to a Pearl or not. :-( > > I would assume that it's the same going forward; 8100, 8800, 83xx, and > so forth. They all have microSD slots, so I would thing the internals > are the same from RIM's engineering perspective. > > Once the 8320 (or the Papa Bear/GPS, if it shows up) releases I'll let > you know. Can't wait. :) > > > The patch you sent added ProductID 0004 to the main() loop, and it would > > cause the device to adjust the charging setting, but not the ProductID, > > and possibly not reset the device either. Is this the behaviour you saw > > with your patch? From just reading the code, it doesn't look like it > > would change the ProductID at all. > > Correct -- my patch was intended to simply find the device when it was > in 0x0004 mode; the 0.6 version of bcharge would simply say "no > devices found", which confused people (here, and on the forums). The > patch was meant to say "hey I found your handset, and it's already at > 500mA". It addressed nothing more than a logic flaw in finding a > device and reporting it's status, it was not meant to add > functionality, really (since if you're at 0x0004 you had to have run > bcharge to get there, usually). > > > As moving from ProductID 0006 to 0004 or 0001 was a one-way affair, > > it seemed reasonable to skip 0004, since you can't do much with it anyway, > > and if it is at 0004 already, then bcharge has run, and the power level > > is good. > > Right, but there are these silly people called "users" who run bcharge > by hand, get "no devices found", and are therefor confused. :) bcharge > should at least report the status of a 0x0004, as per my above (& > patch). > > > This may turn out to be a failed experiment and bcharge will be reverted > > to the older code. :-) > > Well, my opinion is that bcharge should be the KISS principle; it's > purpose in life is to detect a device and adjust the current flow. > Adding more and more code to reset the device into different modes is > outside the scope of this tool, that should be (in my no so humble > opinion :) ) the job of btool or similar. I think that with the > release of 0.7 we might consider updating the build spec for RPMs to > pull bcharge out of barry-tools and put it into it's own barry-bcharge > installable (so no libbarry needed). > > -te > ------------------------------------------------------------------------- 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 Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
