Bug 77881 - gnome-pilot only works with Treo 270 using serial cradle
Summary: gnome-pilot only works with Treo 270 using serial cradle
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-pilot
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Malcolm
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 133127
TreeView+ depends on / blocked
 
Reported: 2002-11-14 18:52 UTC by Michel Alexandre Salim
Modified: 2007-04-18 16:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-31 18:40:47 UTC
Embargoed:


Attachments (Terms of Use)

Description Michel Alexandre Salim 2002-11-14 18:52:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029
Phoenix/0.4

Description of problem:
Using serial cradle my Trio syncs fine, but using the USB cradle it does not
work. JPilot works fine with the same device. I have tried gnome-pilot 0.1.65 as
shipped with RH8, gnome-pilot 0.1.69 from Rawhide, pilot-link 0.11.3 from RH8
and pilot-link 0.11.5 from CVS (with gnome-pilot and j-pilot recompiled against
new pilot-link)

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. set gnome-pilot to use /dev/ttyUSB1 and USB connection
2. synchronise

	

Actual Results:  Trio times out

Expected Results:  Trio synchronise

Additional info:

Older Handspring Visors work fine.

Comment 1 Jeremy Katz 2002-12-29 07:36:13 UTC
Does this work with 0.71 in rawhide?

Comment 2 Michel Alexandre Salim 2003-01-06 16:08:05 UTC
Tried using recompiled pilot-link and gnome-pilot (0.11.5 and 0.1.71
respectively) and I get this; jpilot works as usual

gpilotd-Message: gnome-pilot 0.1.71 starting...
gpilotd-Message: compiled for pilot-link version 0.11.5
gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network]

Gtk-WARNING **: Unable to locate image file in pixmap_path: "mcheck2.png" line 318

Gtk-WARNING **: Unable to locate image file in pixmap_path: "mcheck1.png" line 326

Gtk-WARNING **: Unable to locate image file in pixmap_path: "mcheck2.png" line 318

Gtk-WARNING **: Unable to locate image file in pixmap_path: "mcheck1.png" line 326
gpilotd-Message: Activating CORBA server
gpilotd-Message: Watching Cradle (/dev/ttyS0)
gpilotd-Message: Watching Cradle1 (/dev/ttyUSB1)
gpilotd-Message: setting PILOTRATE=57600

Gtk-WARNING **: cannot open display:


Comment 3 Mauro Majeroni 2003-04-11 10:25:52 UTC
This is the log in messages file.

Apr 11 12:21:33 localhost gnome-name-server[16526]: starting
Apr 11 12:21:33 localhost gnome-name-server[16526]: name server starting
Apr 11 12:21:47 localhost kernel: hub.c: USB new device connect on bus1/1,
assigned device number 12
Apr 11 12:21:47 localhost kernel: usbserial.c: Handspring Visor converter detected
Apr 11 12:21:47 localhost kernel: visor.c: Handspring Visor: Number of ports: 2
Apr 11 12:21:47 localhost kernel: visor.c: Handspring Visor: port 1, is for
Generic use and is bound to ttyUSB0
Apr 11 12:21:47 localhost kernel: visor.c: Handspring Visor: port 2, is for
HotSync use and is bound to ttyUSB1
Apr 11 12:21:47 localhost kernel: usbserial.c: Handspring Visor converter now
attached to ttyUSB0 (or usb/tts/0 for devfs)
Apr 11 12:21:47 localhost kernel: usbserial.c: Handspring Visor converter now
attached to ttyUSB1 (or usb/tts/1 for devfs)
Apr 11 12:21:51 localhost /etc/hotplug/usb.agent: Setup visor for USB product
82d/100/100
Apr 11 12:21:52 localhost kernel: usb.c: USB disconnect on device 12
Apr 11 12:21:52 localhost kernel: usbserial.c: Handspring Visor converter now
disconnected from ttyUSB0
Apr 11 12:21:52 localhost kernel: usbserial.c: Handspring Visor converter now
disconnected from ttyUSB1


Comment 4 Tim Keitt 2003-07-02 15:27:35 UTC
The problem here is a logic error in gpilotd/pilot-link. When you plug a TREO
(not TRIO) into the USB port, it does not initiate a hot-plug connection, so no
serial device is allocated. Try the following. Plug in a Treo and then cat
/proc/bus/usb/devices. Now hit the sync button on the Treo and again cat
/proc/bus/usb/devices. See that the serial device was connected AFTER hitting
the sync button? What gpilotd/pilot-link does is imediately grab the serial line
when it starts and, in the case of a Treo, finds nobody home and that's the end
of it. What it needs to do is wait for the hot-plug event after the sync button
is pressed and THEN grab the serial line. You can emulate this on the command
line. First type "killall gpilotd", then type "gpilotd" BUT DON'T HIT ENTER. Now
hit the sync button on the Treo and count to three. Hit ENTER and watch gpilotd
sync just fine. You may need several tries to get the timing just right. (Too
soon and there's no tty; too late and you miss the Treo's request for a sync
event.) This should be an easy fix. Simply adjust the logic so that gpilotd
polls for the serial line to come up instead of simply bailing as soon as it
finds no connection.

Comment 5 Michel Alexandre Salim 2003-07-23 16:55:50 UTC
Still does not work in RH9 - haven't tried Severn but suspect same case since
it's not even in the changelog for gnome-pilot 2.0.10. Perhaps this should be
filed with Ximian since they maintain the package.. tkeitt, can I quote from
your explanation?

I got my USB cradle running after searching high and low on gnome-pilot lists,
missed your Bugzilla comment.. heh.


Comment 6 Dave Malcolm 2004-11-02 21:27:58 UTC
I'm sorry that this bug has gone for so long without activity.

Have you been able to get this to work with more recent versions of
the packages?  Or are you still seeing this sort of behaviour?

I've been seeing similar behaviour (with gnome-pilot-2.0.12 using a
Tungsten E with a USB connector) to that described in comment #4 (and
have used a similar workaround)

I think the ideal way to fix this will be to integrate HAL support
into gnome-pilot, so I'm marking this as a blocker for bug #133127

Comment 7 Michel Alexandre Salim 2005-10-29 22:01:35 UTC
I no longer have the device with me, so I cannot test this further - should I
close this for now?

Comment 8 Dave Malcolm 2005-10-31 18:40:47 UTC
Thanks for following this up.

I'm going to resolve this bug as "deferred".  Feel free to reopen it if necessary.


Note You need to log in before you can comment on or make changes to this bug.