Re: [coldsync-hackers] usb syncronisation troubles
Alessandro Zummo
sp...@yandex.ru wrote:
>
> AZ> For example, we could implement an ioctl toward the USB layer implemented
> AZ> by libusb.
>
> it's one trouble here
> if at one time several palms are connected to computer how get
> correspondence usb device with /dev/ttyUSBx device file?
> only kernel know about it and i think kernel changes must be done
What if you launch several instances of coldsync, each one with a different
ttyUSBx device?
> >> may be exist other solution? how about hotplug subsystem - can it
> >> collect information about device and call coldsync with right options?
>
> AZ> technically it should.
>
> again - afaik hotpulg don't know about ttyUSBx device
correct ;(
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majo...@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-ha...@thedotin.net.
Alessandro Zummo
sp...@yandex.ru wrote:
> AZ> What if you launch several instances of coldsync, each one with a different
> AZ> ttyUSBx device?
>
> ok
> via libusb call each found several palm devices. each palm have own
> serial number. how coldsync know what serial use?
? each instance will take care of the first unassigned palm... am I
missing something? i'm a bit tired today ;)
sp...@yandex.ru
>> AZ> ttyUSBx device?
>>
>> ok
>> via libusb call each found several palm devices. each palm have own
>> serial number. how coldsync know what serial use?
AZ> ? each instance will take care of the first unassigned palm... am I
AZ> missing something? i'm a bit tired today ;)
what is "first unassigned palm"?
Alessandro Zummo
sp...@yandex.ru wrote:
> >> AZ> What if you launch several instances of coldsync, each one with a different
> >> AZ> ttyUSBx device?
> >>
> >> ok
> >> via libusb call each found several palm devices. each palm have own
> >> serial number. how coldsync know what serial use?
>
>
> AZ> ? each instance will take care of the first unassigned palm... am I
> AZ> missing something? i'm a bit tired today ;)
>
> what is "first unassigned palm"?
i mean the first Palm which is not already syncronizing. I think you'll have to
identify a way to recognize this condition.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
This message was sent through the coldsync-hackers mailing list. To remove
sp...@yandex.ru
>> >> AZ> ttyUSBx device?
>> >>
>> >> ok
>> >> via libusb call each found several palm devices. each palm have own
>> >> serial number. how coldsync know what serial use?
>>
>> AZ> ? each instance will take care of the first unassigned palm... am I
>> AZ> missing something? i'm a bit tired today ;)
it's one of possible solutions, but imho any way in userspace is ugly
and/or not very stable.
examples:
- palm device not listed in kernel visor module (old kernel), but
coldsync know about this model and get serial number from it to other
palm
- hotsync on several palms pressed with very small time difference -
coldsync can swap serial numbers across devices
it's one way without global changes get information from kernel to
userspace - read kernel log. but it's VERY ugly
sp...@yandex.ru
and m500 under linux
i test speed:
- kernel visor driver use 64-byte blocks for usb transfers. if i see
lsusb output i find "wMaxPacketSize 64" line. but via libusb
calls i can do read/write with large blocks without any problem and
with great speed (up to 3 times faster and more)
- uhci kernel driver work faster (up to 1.5 usb-uhci speed). it's not
hardware-related - i do tests on two motherboards (athlon/via and
celeron/intel) and get identical results.
David A. Desrosiers
> - kernel visor driver use 64-byte blocks for usb transfers. if i see
> lsusb output i find "wMaxPacketSize 64" line. but via libusb calls i
> can do read/write with large blocks without any problem and with great
> speed (up to 3 times faster and more)
Have you tried reinstalling the files you back up with a packet size
larger than 64k? No doubt, they'll be trashed, with corrupt records, even
though the byte size of the .prc/.pdb is identical.
d.
sp...@yandex.ru
>> lsusb output i find "wMaxPacketSize 64" line. but via libusb calls i
>> can do read/write with large blocks without any problem and with great
>> speed (up to 3 times faster and more)
DAD> Have you tried reinstalling the files you back up with a packet size
DAD> larger than 64k?
64 bytes, not 64 kb
DAD> No doubt, they'll be trashed, with corrupt records, even though
DAD> the byte size of the .prc/.pdb is identical.
ok, i try it tommorow
sp...@yandex.ru
>>> lsusb output i find "wMaxPacketSize 64" line. but via libusb calls i
>>> can do read/write with large blocks without any problem and with great
>>> speed (up to 3 times faster and more)
DAD>> Have you tried reinstalling the files you back up with a packet size
DAD>> larger than 64k?
syr> 64 bytes, not 64 kb
DAD>> No doubt, they'll be trashed, with corrupt records, even though
DAD>> the byte size of the .prc/.pdb is identical.
syr> ok, i try it tommorow
i try it - all work fine. i don't test palm records over 64kb or dlp
packets over 64 kb, i test transfer via usb with low-level packet size
over 64b (may be kernel split usb transfers to 64 bytes-blocks - but
why speed increase?).
ps: what about dlp-packets over 64kb? how can i test it with coldsync?
sp...@yandex.ru
today libusb code work for me under linux with:
palm m500 (palmos 4.1), tungsten t (palmos 5.0)
sony 415, sj-20, sj-22 (palmos 4.1)
on this week i try test it with sony 320 and 610
if anybody can test this code with other hardware or other os - please
do it and report results to me.
i think problems can be with:
- treo
- old sony (palmos 3.5)
- sony with palmos 5.x
- original visor
- any other ;)))
i use cvs version of coldsync and visor.h from kernel version 2.4.23
2. speed
i test full backup under windows - it work fast, but this libusb code
slightly faster.
3. PConnection_usb.c
i see freebsd usb code - it duplicate libusb code. may be remove it
from coldsync tree? libusb is small and portable wrapper.
Alessandro Zummo
sp...@yandex.ru wrote:
>
> if anybody can test this code with other hardware or other os - please
> do it and report results to me.
I should be able to test it with a m505 (4.1), a Tungsten E and T3 in the next few days.
>
> 3. PConnection_usb.c
> i see freebsd usb code - it duplicate libusb code. may be remove it
> from coldsync tree? libusb is small and portable wrapper.
It is something we were thinking about... Andrew?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
This message was sent through the coldsync-hackers mailing list. To remove
Andrew Arensburger
> On Wed, 3 Dec 2003 15:09:50 +0300
> sp...@yandex.ru wrote:
> > 3. PConnection_usb.c
> > i see freebsd usb code - it duplicate libusb code. may be remove it
> > from coldsync tree? libusb is small and portable wrapper.
>
> It is something we were thinking about... Andrew?
Sorry for taking so long.
As I understand it, ColdSync+libusb for FreeBSD requires a
kernel module for serial communications (I forget the name right now).
This module is included with FreeBSD 5.x, but not 4.x.
5.x isn't quite ready yet, but should be released relatively
soon. So I vote to wait until 5.x becomes the new stable version.
--
Andrew Arensburger This message *does* represent the
are...@ooblick.com views of ooblick.com
"Let us be charitable, and call it a misleading feature :-)"
-- Larry Wall
sp...@yandex.ru
>> > i see freebsd usb code - it duplicate libusb code. may be remove it
>> > from coldsync tree? libusb is small and portable wrapper.
>>
>> It is something we were thinking about... Andrew?
AA> Sorry for taking so long.
AA> As I understand it, ColdSync+libusb for FreeBSD requires a
AA> kernel module for serial communications (I forget the name right now).
why? i think libusb use only usb-subsystem from kernel, but not usb
devices drivers
sp...@yandex.ru
>> AZ> by libusb.
>>
>> it's one trouble here
>> if at one time several palms are connected to computer how get
>> correspondence usb device with /dev/ttyUSBx device file?
>> only kernel know about it and i think kernel changes must be done
AZ> What if you launch several instances of coldsync, each one with a different
AZ> ttyUSBx device?
ok
via libusb call each found several palm devices. each palm have own
serial number. how coldsync know what serial use?
This message was sent through the coldsync-hackers mailing list. To remove
Greg KH
> >> >> AZ> What if you launch several instances of coldsync, each one with a different
> >> >> AZ> ttyUSBx device?
> >> >>
> >> >> ok
> >> >> via libusb call each found several palm devices. each palm have own
> >> >> serial number. how coldsync know what serial use?
> >>
> >> AZ> ? each instance will take care of the first unassigned palm... am I
> >> AZ> missing something? i'm a bit tired today ;)
>
> it's one of possible solutions, but imho any way in userspace is ugly
> and/or not very stable.
>
> examples:
> - palm device not listed in kernel visor module (old kernel), but
> coldsync know about this model and get serial number from it to other
> palm
> - hotsync on several palms pressed with very small time difference -
> coldsync can swap serial numbers across devices
>
> it's one way without global changes get information from kernel to
> userspace - read kernel log. but it's VERY ugly
Catch the hotplug event for when the visor device is added to the
system. Isn't very hard to do at all with the latest version of the
linux-hotplug core package.
greg k-h