Re: Treo 300: pilot-link works, gnome-pilot doesn't
- From: Adam C Powell IV <hazelsct mit edu>
- To: gnome-pilot-list gnome org
- Subject: Re: Treo 300: pilot-link works, gnome-pilot doesn't
- Date: Fri, 14 Mar 2003 09:30:59 -0500
Hello again,
Adam C Powell IV wrote:
David A. Desrosiers wrote:
Funny thing is, if gpilotd is running and I push sync, the device hangs
and never times out. If I then run pilot-xfer, it sees /dev/ttyUSB1
and
tries to start syncing, but *then* the device times out (and
disconnects).
What version of gnome-pilot are you using?
What version of pilot-link was it built against?
0.1.71-5 Debian woody backport, 0.11.7-2 backport.
So is only 2.0.1 supported now? I'd be happy to do some maintenance on
the old versions, since I'm not planning to upgrade to GNOME 2.* for
some time.
So I think something is wrong in gpilotd's assumptions about when
things
will happen. Perhaps it isn't monitoring /dev/ttyUSB1 like it says
it is,
because there's no such device before sync?
gnome-pilot doesn't read the Treo device info from /proc, because as
you probably figured out, /proc/bus/usb/devices for these newer
devices (OS5
devices, Treo, etc.) do not have the string "Palm Handheld" in them
as they
did previously (gpilotd/gpilotd.c in struct product_names). This has
to be
patched to handle the lookups for the actual product_id and the
vendor_id
(in this case, 082d and 200 respectively). I think someone did this
for the
Tungsten awhile back on this list. You might want to search the
archives.
Actually, the treo 300 is showing up as 082d and 0100, like a plain
Visor. Here's what shows up in /proc/bus/usb/devices:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=082d ProdID=0100 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA
I: If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=serial
E: Ad=01(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=1ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
There's no "Palm" or "Handspring" anywhere, so no match to anything in
product_names. Perhaps a more involved patch is required? I'd be
glad to help...
So we have a device which doesn't give its name. What to do? It seems
we can either:
* Make an "exception" loop, after the main loop which checks the
names for a match; this exception loop would trigger if the main
loop didn't see anything and check for the one (or more?) Vendor
and ProdIDs which correspond to devices without names.
* Switch entirely to using Vendor and ProdID instead of name,
copying in some of the values from kernel visor.h.
I'd be happy to code either of these, test, and send a patch to the
list. If nobody replies, I'll do the first of the two, probably early
next week..
Cheers,
--
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]