On Sun, Feb 15, 2009 at 11:06:05AM +0100, Nicolas wrote:
> Don't forget this fix... it's usefull for Barry 0.15.
Thanks for the reminder and the patch! Applied.
Have you tested for Calendar entries? I'm assuming this may be needed
for all database records.
I don't have a Storm, so I can't test
On Sun, Feb 15, 2009 at 11:06:05AM +0100, Nicolas wrote:
> Don't forget this fix... it's usefull for Barry 0.15.
FYI, I've rebased the opensync-0.4x branch onto the latest master, including
this fix.
- Chris
--
Open Sou
Attached is a patch that implements the device reset.
It seemed most appropriate to put the reset into SocketZero::Close
since Windows javaloader doesn't start the reset sequence until the
close command is sent.
While sending the reset command conditionally from
JavaLoader::StopStream does work,
Chris,
I have added a few USB captures and documentation for the reset
sequence here:
http://www.slashdev.ca/usbcap
You already have most of these already, here is a list of the ones that
need to be added to the archive:
- deviceinfo.usb.gz
- deviceinfo.txt
- save-large.usb.gz
- save-very-large
Don't forget this fix... it's usefull for Barry 0.15.
Le vendredi 13 février 2009 à 11:24 +0100, Nicolas a écrit :
> I forgot ; this issue is also present with opensync plugin 0.22.
>
> On Thu, Feb 12, 2009 at 03:15:57PM +0100, Nicolas wrote:
> > Hi,
> >
> > I have found an other little bug with
On Sun, Feb 15, 2009 at 03:09:38AM -0500, Josh Kropf wrote:
> In my testing I've found that only
> one of the packets sent during this sequence is required (the last one)
> and it doesn't seem to mater if it is sent before or after closing
> socket zero.
That's good to know. Some of those packets
On Sun, 15 Feb 2009 02:37:56 -0500
Chris Frey wrote:
> If, in what I guess to be the more likely scenario, you can use these
> packets at any time to reset the device, without even opening one of
> the "modes", put it in the SocketZero class, and call it conditionally
> on 0x78 in JavaLoader.
Ye