Re: Treo 300: pilot-link works, gnome-pilot doesn't



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]