Thread: [Barry-devel] Calling all Pearl users
Status: Beta
Brought to you by:
ndprojects
From: Chris F. <cd...@fo...> - 2007-03-16 20:13:08
|
Hi folks, I need to double check something in the Pearl device numbers, in order to know whether I can rely on the iProduct code to tell me if it is a Pearl or not. So if you could report the following lines from your "lsusb -v" output, that would be most helpful: idVendor 0x0fca Research In Motion, Ltd. idProduct 0x0004 bcdDevice 1.06 iManufacturer 1 Research In Motion iProduct 5 RIM Composite Device idProduct can be 0x0001, 0x0004, or 0x0006. I'm mostly interested to know if iProduct is consistently a 5 on Pearl devices. Thanks! - Chris P.S. Troy and Miles, I know your devices are 5's, from your lsusb posts, so you don't have to do this again. :-) Thanks. |
From: troy e. <te...@so...> - 2007-03-17 16:43:51
|
On 3/16/07, Chris Frey <cd...@fo...> wrote: > > I'm mostly interested to know if iProduct is consistently a 5 on Pearl > devices. Nope, when it's device 0x0006 it's iProduct = 4. From the newest bcharge (I'll reply in that thread about this), I see: idVendor 0x0fca Research In Motion, Ltd. idProduct 0x0006 bcdDevice 1.06 iManufacturer 1 Research In Motion iProduct 4 RIM Mass Storage Device I just checked, if I just rename bcharge so it doesn't run, this is the default state (@ 100mA) of the device when plugged in. -te -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-17 17:39:13
|
On Sat, Mar 17, 2007 at 09:43:48AM -0700, troy engel wrote: > Nope, when it's device 0x0006 it's iProduct = 4. From the newest > bcharge (I'll reply in that thread about this), I see: > > idVendor 0x0fca Research In Motion, Ltd. > idProduct 0x0006 > bcdDevice 1.06 > iManufacturer 1 Research In Motion > iProduct 4 RIM Mass Storage Device Thanks! What number is it when idProduct is 0x0001, if you use an old bcharge -o? - Chris |
From: troy e. <te...@so...> - 2007-03-17 21:01:03
|
On 3/17/07, Chris Frey <cd...@fo...> wrote: > > Thanks! What number is it when idProduct is 0x0001, if you use an old > bcharge -o? You have to do this manually since the logic loop missing 0x0004 is missing in older bcharge, so I renamed mine to bcharge.rpm. Starting from a raw plugin (0x0006) the running ./bcharge.rpm -o, I get: idVendor 0x0fca Research In Motion, Ltd. idProduct 0x0001 Blackberry Handheld bcdDevice 1.06 iManufacturer 1 Research In Motion iProduct 2 BlackBerry Device If you run ./bcharge.rpm all by itself, it says: Scanning for Blackberry devices... Found...already at 500mA 0 device adjusted. It does *not* re-reset to 0x0004 as I think you intended. This is the classic bcharge without my patch, 0.6 alpha code. 0.6 + my simple patch sort of made everything work right, CVS seems a lot more broken and complicated. -te -- some live, some die in the way of the samurai |
From: Chris F. <cd...@fo...> - 2007-03-21 21:01:46
|
On Sat, Mar 17, 2007 at 02:01:01PM -0700, troy engel wrote: > You have to do this manually since the logic loop missing 0x0004 is > missing in older bcharge, so I renamed mine to bcharge.rpm. Starting > from a raw plugin (0x0006) the running ./bcharge.rpm -o, I get: > > idVendor 0x0fca Research In Motion, Ltd. > idProduct 0x0001 Blackberry Handheld > bcdDevice 1.06 > iManufacturer 1 Research In Motion > iProduct 2 BlackBerry Device Thanks. Looks like I can't use iProduct as a way to determine whether I'm talking to a Pearl or not. :-( > If you run ./bcharge.rpm all by itself, it says: > > Scanning for Blackberry devices... > Found...already at 500mA > 0 device adjusted. > > It does *not* re-reset to 0x0004 as I think you intended. This is the > classic bcharge without my patch, 0.6 alpha code. 0.6 + my simple > patch sort of made everything work right, CVS seems a lot more broken > and complicated. Yes, at the moment this is true... but it was in the name of added functionality, which your patch didn't provide, unless I'm missing something? 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. 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. I was trying to split the charge behaviour and the Pearl mode behaviour in the new code, but there is no reliable way that I've found to determine if a ProductID 0001 device is a Pearl or not, so returning from mode 0001 to 0004 is something I can't seem to autodetect. This may turn out to be a failed experiment and bcharge will be reverted to the older code. :-) I'm interested in your thoughts on this. Thanks, - Chris |
From: troy e. <te...@so...> - 2007-03-22 17:31:56
|
On 3/21/07, Chris Frey <cd...@fo...> 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 -- How can anyone hate Canadians? It's like hating bread. [Matt Harding] |
From: Rick S. <rw...@al...> - 2007-03-22 22:10:58
|
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 <cd...@fo...> 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 > |
From: Chris F. <cd...@fo...> - 2007-03-29 20:45:20
|
On Thu, Mar 22, 2007 at 06:04:02PM -0400, Rick Scott wrote: > 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. Hi Rick! Don't stay quiet. :-) Has Greg KH been able to get his hands on the Recommended Procedure (TM) for adjusting power and the Pearl modes? As you've probably seen on the list, people have been running into some pretty funky behaviour, with endpoints being 0, and firmware upgrades solving the issue. I imagine there is a "Windows way" that just hasn't been discovered yet. Also, you mention the usb_storage / database access conflict. I'm curious how you see that being fixed. These two pieces of functionality come in two different USB configurations, and it is my understanding that USB cannot select both configurations at the same time. Pretending to have both running at the same time will require code, somewhere, either in kernel or not, to switch wildly back and forth between these two USB configurations. Either that, or just make usb_storage politely give up its claim on request. I seem to recall other drivers doing this when I was reading through the kernel source, but can't recall which driver anymore. If anyone has a Pearl handy, with Windows, I'm curious if it is possible to do a backup of the device at the same time as having it mapped to a drive. > 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 .... Do you have lsusb -v output for that device, by any chance? Thanks, - Chris |
From: Rick S. <rw...@al...> - 2007-03-29 22:17:14
|
On Thu, 2007-03-29 at 16:44 -0400, Chris Frey wrote: > On Thu, Mar 22, 2007 at 06:04:02PM -0400, Rick Scott wrote: > > 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. > > Hi Rick! Don't stay quiet. :-) > > Has Greg KH been able to get his hands on the Recommended Procedure (TM) > for adjusting power and the Pearl modes? As you've probably seen on the > list, people have been running into some pretty funky behaviour, with > endpoints being 0, and firmware upgrades solving the issue. I was just referring to the patch he already posted. I think that was before Pearl. > > I imagine there is a "Windows way" that just hasn't been discovered yet. > > Also, you mention the usb_storage / database access conflict. I'm curious > how you see that being fixed. These two pieces of functionality come in > two different USB configurations, and it is my understanding that USB > cannot select both configurations at the same time. Pretending to have > both running at the same time will require code, somewhere, either in > kernel or not, to switch wildly back and forth between these two > USB configurations. I mean a way to have usb_storage not grab the device. If the udev rule can get matched early enough, and the mode switched out of storage, this shouldn't be an issue. > > Either that, or just make usb_storage politely give up its claim on > request. I seem to recall other drivers doing this when I was > reading through the kernel source, but can't recall which driver anymore. > > If anyone has a Pearl handy, with Windows, I'm curious if it is possible > to do a backup of the device at the same time as having it mapped to > a drive. > > > > 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 .... > > Do you have lsusb -v output for that device, by any chance? That would have been a really good thing to keep :( It seemed to behave the way that I've heard the pearl described here. > > Thanks, > - Chris |