I've looked up the Kpilot manual, and I think I have an okay idea of what's going on with it.
I'm trying to get it's detection feature to find my Palm Pilot. CentOS does seem to be able to recognize it, because if I run lsusb when running a hot sync, I get the following:
[root@localhost dev]# lsusb Bus 001 Device 010: ID 0830:0060 Palm, Inc. Palm Tungsten T / Zire 71
That's encouraging. My Palm Pilot is actually a Tungsten E, not a T, but I'm not sure that's a level of detail that matters at this point.
The Kpilot documentation suggest that I look for the palm pilot at /dev/ttyUSB0. That didn't work, but I noticed in my /dev/ directory that there was also a ttyUSB1. That didn't work either. But then I noticed that both were only apparent when I was hot syncing my Palm, so they must be connected to it.
Any ideas, then, as to why Kpilot is not acknowledging them as a Palm device the way that lsusb does?
Dave
Dave Gutteridge wrote:
The Kpilot documentation suggest that I look for the palm pilot at /dev/ttyUSB0. That didn't work, but I noticed in my /dev/ directory that there was also a ttyUSB1. That didn't work either. But then I noticed that both were only apparent when I was hot syncing my Palm, so they must be connected to it.
Any ideas, then, as to why Kpilot is not acknowledging them as a Palm device the way that lsusb does?
I've wrestled with this one before. I believe that udev creates the /dev/ttyUSB0 or ttyUSB1 once the "sync" button is pressed on the cradle. I had to do something with udev in order to get it to create a /dev/pilot symlink to this device on every boot, but at the moment I don't have access to the machine to tell you what it was.
Also, I suggest trying to start with dlpsh to diagnose any problems. It is a command line utility for accessing your palm device. I've found that it gives much better feedback than Kpilot or Gpilot. It is included with the pilot-link package on CentOS 4.
Hope this helps,
--Shawn
I've wrestled with this one before. I believe that udev creates the /dev/ttyUSB0 or ttyUSB1 once the "sync" button is pressed on the cradle. I had to do something with udev in order to get it to create a /dev/pilot symlink to this device on every boot, but at the moment I don't have access to the machine to tell you what it was.
Thank you for your advice. I successfully connected to my palm by starting the hotsync process, then running dlpsh at the command line, listening on port /dev/ttyUSB1.
However, using /dev/ttyUSB1 in Kpilot produced no results.
But with this new information, I looked up the Kpilot documentation, and found myself at this page: http://www.gadgetreview.com/guides/palm-under-linux.html
Which had instructions for Fedora Core 1, but I thought it might be close enough. It instructed that I try the following:
cd /dev ln -s ttyUSB1 pilot ln -s ttyUSB1 palm chmod 0666 pilot palm
And then I tried connecting through /dev/pilot, /dev/palm, and /dev/ttyUSB1. But it was unsuccesful.
So at this stage it seems that the USB connection is okay, the palm pilot is okay, but Kpilot is not. Or there could still be some other issue that I don't know about.
Any ideas what I can try next?
Dave
Shawn M. Jones wrote:
Dave Gutteridge wrote:
The Kpilot documentation suggest that I look for the palm pilot at /dev/ttyUSB0. That didn't work, but I noticed in my /dev/ directory that there was also a ttyUSB1. That didn't work either. But then I noticed that both were only apparent when I was hot syncing my Palm, so they must be connected to it.
Any ideas, then, as to why Kpilot is not acknowledging them as a Palm device the way that lsusb does?
I've wrestled with this one before. I believe that udev creates the /dev/ttyUSB0 or ttyUSB1 once the "sync" button is pressed on the cradle. I had to do something with udev in order to get it to create a /dev/pilot symlink to this device on every boot, but at the moment I don't have access to the machine to tell you what it was.
Also, I suggest trying to start with dlpsh to diagnose any problems. It is a command line utility for accessing your palm device. I've found that it gives much better feedback than Kpilot or Gpilot. It is included with the pilot-link package on CentOS 4.
Hope this helps,
--Shawn
Hi Dave,
I own a Palm Tungsten E too and I was able to sync it successfully with jpilot (http://www.jpilot.org). The same procedure should work with KPilot since it is also a front-end to pilot-link.
Actually, /dev/ttyUSB1 is the sync port... but it can be also /dev/ttyUSB3 or /dev/ttyUSB5... Thanks to udev, each time you press the hotsync button, there is no waranty that your sym port will always be /dev/ttyUSB1. The problem is that KPilot (and jpilot too) will look for /dev/pilot simlink. The trick is to add a rule for udev so it can map /dev/ttyUSB[13579] to /dev/pilot. So, as root, open a text editor (kedit, emacs, etc) and create a new file named 10-visor-rules under /etc/udev/rules.d
Put this line inside that file: BUS="usb", SYSFS {product}="Palm Handheld", KERNEL="ttyUSB[13579]", SYMLINK="pilot"
Save it and try to push the hotsync button on you Tungsten E. If you do a ls -l on /dev/pilot you should see something the simlink: pilot -> ttyUSB1
Now, try again to sync in KPilot. It worked for me!
Good luck!
Etienne.
Save it and try to push the hotsync button on you Tungsten E. If you do a ls -l on /dev/pilot you should see something the simlink: pilot -> ttyUSB1 Now, try again to sync in KPilot. It worked for me!
Thank you for that very helpful advice. I at least understand what's going on more. I did as you advised, and I see this when I run ls -l /dev/pilot:
[root@localhost rules.d]# ls -l /dev/pilot lrwxrwxrwx 1 root root 7 Aug 5 18:19 /dev/pilot -> ttyUSB1
It seems to be as you predict. Except I notice that /dev/pilot is *always* a symlink to ttyUSB1, whether the palm is connecting or not.
Is it possible that when I did this: cd /dev ln -s ttyUSB1 pilot ln -s ttyUSB1 palm chmod 0666 pilot palm
... previous to getting your advice, I created a symlink that is over riding what is in 10-visor-rules?
If so, can I remove my previous symlinks so that 10-visor-rules will take effect?
Dave
I went ahead figured out how to remov the symbolic links, and I played around with Kpilot a little more.
1. I notice that the symbolic link "pilot" is not being created when I press the hotsync button. Is 10-visor-rules being used by the system?
2. In Kpilot, I went past the wizard and tried to establish a connection manually to ttyUSB1. In the log I noticed this: Pilot device /dev/ttyUSB1 is not read-write. Perhaps there is a permission problem? How can I make sure ttyUSB1 is user readable/writable when it's only created each time the pilot syncs?
Dave
On Fri, 2005-08-05 at 21:23 +0900, Dave Gutteridge wrote:
I went ahead figured out how to remov the symbolic links, and I played around with Kpilot a little more.
- I notice that the symbolic link "pilot" is not being created when I
press the hotsync button. Is 10-visor-rules being used by the system?
- In Kpilot, I went past the wizard and tried to establish a connection
manually to ttyUSB1. In the log I noticed this: Pilot device /dev/ttyUSB1 is not read-write. Perhaps there is a permission problem? How can I make sure ttyUSB1 is user readable/writable when it's only created each time the pilot syncs?
---- 1 - $ cat /etc/udev/rules.d/10-udev.rules KERNEL="ttyUSB1",SYMLINK="pilot"
$ cat /etc/udev/permissions.d/10-udev.permissions #set Palm Pilot rwx pilot*:root:usb:0666 pilot*:craig:usb:0666
2 - when you have pushed the sync button on the cradle...
ls -l /dev/ttyUSB* /dev/pilot
see if they exist and who owns them
Craig
when you have pushed the sync button on the cradle... ls -l /dev/ttyUSB* /dev/pilot see if they exist and who owns them
Thank you for the instructions. This is what I get from the ls command you suggested:
[root@localhost dave]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Aug 5 21:47 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Aug 5 21:47 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Aug 5 21:47 /dev/ttyUSB1
Does this mean that root owns them, but that they are accessible by anyone.
And then...
Hey! It works! Wow... I totally expected to run Kpilot to get some other error or something... but it works. As I write this my palm device is being backed up to the computer.
Sweet!!
Thanks everyone for helping me get this running. I'm now just one step away from the perfect operating system.
Dave
On Fri, Aug 05, 2005 at 09:52:56PM +0900, Dave Gutteridge enlightened us:
when you have pushed the sync button on the cradle... ls -l /dev/ttyUSB* /dev/pilot see if they exist and who owns them
Thank you for the instructions. This is what I get from the ls command you suggested:
[root@localhost dave]# ls -l /dev/ttyUSB* /dev/pilot lrwxrwxrwx 1 root root 7 Aug 5 21:47 /dev/pilot -> ttyUSB1 crw-rw---- 1 root uucp 188, 0 Aug 5 21:47 /dev/ttyUSB0 crw------- 1 dave uucp 188, 1 Aug 5 21:47 /dev/ttyUSB1
Does this mean that root owns them, but that they are accessible by anyone.
Almost. The symbolic link is accessible by any, however the file it points to is what determines the permissions needed to access the file.
ttyUSB0 is readable and writeable by root, and is readable and writeable by the uucp group.
ttyUSB1 is readable and writeable by dave
And then...
Hey! It works! Wow... I totally expected to run Kpilot to get some other error or something... but it works. As I write this my palm device is being backed up to the computer.
That's because your user has permission to access it now :-)
Sweet!!
Thanks everyone for helping me get this running. I'm now just one step away from the perfect operating system.
If you have problems, you know where to find us ;-)
Matt
-
Craig White -
Dave Gutteridge -
Etienne Savard -
Matt Hyclak -
Shawn M. Jones