Gentoo Wiki


This article is part of the HOWTO series.
Installation Kernel & Hardware Networks Portage Software System X Server Gaming Non-x86 Emulators Misc



After reading this article, you will be able to use a Palm-based PDA to sync data via the USB connection with Evolution 2.0 on a system running the 2.6 kernel, udev, and NPTL.


System Requirements

Software Requirements


Linux Kernel Configuration: Device Drivers --> USB Support --> USB Serial Converter support
       <M> USB Serial Converter support
       [*]   USB Generic Serial Driver
       <M>   USB Handspring Visor / Palm m50x / Sony Clie Driver

Phase 1: Making Linux recognize the PDA

First, plug the PDA into the system and hit the hotsync button on the PDA. As root, run lsusb and see if anything comes up involving Palm, Visor, or PDAs. If so, great. If you don't see any output related to your PDA, you most likely have a hardware problem. Make sure everything is plugged in snugly, try a different USB port on your computer, try a different device in that port and see if that shows up in lsusb, etc.

Next, recompile your kernel with support for your PDA as a module. These modules are usually listed under Device Drivers/USB Support/USB Serial Converter Support. You should select USB Serial Converter Support as a module, then select the Generic driver (the one listed under what you just selected), and the proper PDA driver that you need. Palm PDAs should use the Visor module. If you do not see the USB Serial Converter support option, ensure that you have 'Nonstandard serial support' enabled under Device Drivers/Character Devices.

After rebooting, you should be able to 'modprobe visor', you can push the HotSync button on your device and see some output about your device after issuing dmesg.

Linux can now see the PDA, and you have the driver for it, but you have to tell Gentoo that it should use the visor driver for the PDA, and that it should create the proper device nodes under /dev. Instead of editing /etc/udev/rules.d/50-udev.rules, consider creating /etc/udev/rules.d/10-udev.rules, since the former may contain default udev rules.

udevinfo -p /sys/class/tty/ttyUSB1 -a, this should output some relevant information (look for lines pertaining to your device).

Now, create and/or edit /etc/udev/rules.d/10-udev.rules using your favorite editor to look like something similar to this, change the 'serial' string to match your device's actual serial number:

File: /etc/udev/rules.d/10-udev.rules
# PalmOne Tungsten T3

Note: you should be able to find your device's serial number using cat /proc/bus/usb/devices after hitting the hotsync button.

This should be sufficient to identify an individual device (by serial number). Not all Palms have a serial number, but they have plenty of information to help you identify them, for example you could use iManufacturer:

File: /etc/udev/rules.d/10-udev.rules
# Visor Neo
BUS=="usb",SYSFS{manufacturer}=="Handspring Inc",NAME="pilot"

If you do not want only root to be able to use the device, use the following line instead:

File: /etc/udev/rules.d/10-udev.rules
# PalmOne Tungsten T3
# This works for one user's Handspring Visor.  Put the desired user in the "usb" group.
KERNEL=="ttyUSB[01]*",  NAME="tts/USB%n", GROUP="usb", MODE="0660"

Now do another hotsync, then look at the output of dmesg. It should say something about recognizing the PDA and loading the appropriate driver. A look at the output of lsmod will confirm that the right driver was loaded. Also, see that the device node (/dev/pilot) was created.

After completing this phase, you should have a system that recognizes the PDA, and is ready to do data syncing.

You also should be in the tty group, if not add yourself with gpasswd -a user tty as root. Then log out and back in and it should work.

Phase 2: Communicating with the PDA

Start off by attempting to get the basic information about the PDA. Run pilot-xfer --port /dev/tts/USB1 --list and hit the hotsync button on the PDA when prompted. It should spit out a list of information. We're not terribly interested in the information, just the fact that communication is possible.

Note: If it reports something like...

  The device /dev/tts/USB1 does not exist..
  Possible solution:
mknod /dev/tts/USB1 c <major> <minor>
Unable to bind to port: /dev/tts/USB1 Please use --help for more information means that your udev daemon is not creating the right /dev/tts/USB* files. But if you run pilot-xfer AFTER pressing HotSync button, the pilot-xfer does not report the problem, and USB* show up in the /dev/tts dir. Try changing from USB1 to USB0, or try using /dev/pilot after pressing the HotSync button.

Now it is time to use Evolution. Make sure that the pda use flag was set when you emerged Evolution or else the needed conduits will not be available. When you are ready, start Evolution and run the Gnome-Pilot wizard under Tools/Pilot Settings. Put /dev/tts/USB1 (or USB0) in the in the Port field, and select USB. Remember to use the USB device that works with pilot-xfer!

If all goes well, that should be it! You can then fiddle with the software to your heart's content.

Adding support for your Handheld

If you have uncommon or bleeding-edge hardware, chances are that gnome-pilot can't handle it. This could be the case if communication with the handheld is non-existent. It's time to make use of gnome-pilot's GPL licence, and edit some code!

Make sure your handheld is properly connected and trying to perform a hotsync. Open a terminal:

cat /proc/bus/usb/devices

Locate your device's vendor(Vendor=00XX) and it's product id(ProdID=00XX).

Then, use your favorite text editor to edit /usr/share/gnome-pilot/devices.xml (i.e., 'nano /usr/share/gnome-pilot/devices.xml') and add the following line:

<device vendor_id="00XX" product_id="00XX" />

Recompile, and voila...

Some personal troubleshooting

Not sure if other people have struggled with this or not, but I sure had problems getting this to work.

Running gentoo-2.6.12-r6 with coldplug, hotplug and udev. Essentially the dev/tts1/USB0 and dev/tts1/USB1 devices were only getting instantiated after I hit the sync button on my palm. However the jpilot process is to hit sync on jpilot and then hit sync on your palm. Problem is that jpilot quits because the devices come online because the devices aren't created until I hit the sync button on my palm. The two never sync'd up...

I'm sure there is a better answer than where I ended up (hoping for comments), but it works for now so...

First I tried editing the udev rules to create the proper devices and links as stated above. Worked fine, but whenever my PDA wasn't actively sync'ing the devices (and links) would disappear. But this didn't work because of the race condition mentioned above...

Next I tried adding the devices to the Hotplug blacklist, but that seems to only prevent hot plug from creating the devices and doesn't seem to prevent hotplug from deleting them. So I'd create the devices in local.start and they'd be there after boot, but after the first sync they would disappear again.

The final solution I came up with was simply to create the devices I needed in local.start as follows:

File: /etc/conf.d/local.start
 # make palm pilot nodes a boot
 mkdir -m 0755 /dev/tts# KERNEL="ttyUSB[0-9]*",  NAME="tts/USB%n", GROUP="tty", MODE="0600"
 mknod -m 0666 /dev/tts/USB0 c 188 0
 mknod -m 0666 /dev/tts/USB1 c 188 1
 ln -s /dev/tts/USB0 /dev/pilot0
 ln -s /dev/tts/USB1 /dev/pilot1

I then went into the udev rules and commented out any reference to usb serial

File: /etc/udev/rules.d/50-udev.rules
 # KERNEL=="ttyUSB[0-9]*",  NAME="tts/USB%n", GROUP="tty", MODE="0600"

This basically leaves me with the usb links being permanently enabled and never torn dowm by hotplug.

The only side effect I've seem from this is that coldplug coughs during boot about the devices already existing but otherwise everything works fine.

If there is a "cleaner", or more appropriate way to make this work, I'd sure love hear it though I'm not currently experiencing any problems.

I will however have to "re-edit" the udev rules the next time udev gets updated.

Solution to personal troubleshooting

The following link helps a lot:

Entering this single line in 10-udev.rules solved my problem as the other claims... BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot"

To connect my Palm TX I used the following rule:


KERNEL="ttyUSB[13579]", NAME="pilot", GROUP="usb", MODE="0660"

In J-Pilot I use the following device: /dev/pilot

For my Zire m150 the udev rule beginning with "BUS=..." doesnt work, the one beginning with 'KERNEL=..." is fine.

For my Zire 21, this line worked:

BUS=="usb",SYSFS{manufacturer}=="Palm, Inc.",NAME="pilot",OWNER="root",KERNEL=="ttyUSB[13579]",GROUP="tty"

the normal user must be in the tty group

For Clie TH-55

  1. Sony Clie TH-55


For my Sony Clie, I needed to use the first of the two ttyUSB ports it created & I couldn't assume that they would be odd or even as I also use a USB->serial converter sometimes. My 10-udev.rules entry looked like this:

BUS=="usb",SYSFS{product}=="Palm Handheld",KERNEL=="ttyUSB*",NAME="pilot%n"

This way, that it'll only intercept any /dev/ttyUSB devices claiming to be "Palm Handhelds" (and not my serial port) and, instead of only creating one /dev/pilot (which, of course, was the one of the two that didn't work) it creates two. I then simply updated kpilot to use /dev/pilot1 instead of /dev/pilot and everything works great.

Retrieved from ""

Last modified: Mon, 06 Oct 2008 13:28:00 +0000 Hits: 44,521