Bug 77881 - gnome-pilot only works with Treo 270 using serial cradle
gnome-pilot only works with Treo 270 using serial cradle
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: gnome-pilot (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
:
Depends On:
Blocks: 133127
  Show dependency treegraph
 
Reported: 2002-11-14 13:52 EST by Michel Alexandre Salim
Modified: 2007-04-18 12:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-31 13:40:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2002-11-14 13:52:10 EST
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 02:36:13 EST
Does this work with 0.71 in rawhide?
Comment 2 Michel Alexandre Salim 2003-01-06 11:08:05 EST
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 06:25:52 EDT
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 11:27:35 EDT
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 12:55:50 EDT
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 16:27:58 EST
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 18:01:35 EDT
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 13:40:47 EST
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.