Piloting Blind, Chapter 1

So I've been trying to get my Palm (more specifically, the original Handspring Visor) to work with my PC-BSD machine. I installed JPilot, which seems to be a very nice freeware Palm desktop program. I was even able to import my Windows Palm desktop settings into it, and it looks pretty solid. I need to look into the alarms a little more, as I don't really want an 11mb program hanging around just to remind me to pick up my daughters even now and then. But still, that step went pretty smoothly. And if I was real good about it, I would make a PBI.

The next step was to get it to send the data down to my Palm, via its USB connection. This was a whole new ballgame. Of course, just plugging it in and hitting the HotSync button didn't work. Nor did clicking on the sync button on JPilot, as it couldn't open the device. It was looking for /dev/pilot, and it wasn't there. So I needed more details.

This lead me into the netherworld of /etc/devfs.conf (for setting up devices at boot time), /etc/devfs.rules (for setting up devices at runtime), /etc/usb.conf (for setting up actions when USB devices get connected), and /etc/devd.conf (actions on kernel events like attach and detach). Phew - so many ways to do a simple task!

Despite some great help on the FreeBSD.questions list (special shout-outs to both Anish and Damien for their patience), I still can't get it to quite work. At first, the Visor would just time out and not notice anything had tried to access it. After more struggles, I would at least get the reassuring 'beep beep' from the cradle that said something was coming across, but still no joy. Now, I can get it to download data from the Visor, but I can't seem to upload it. Here's what I did to get this far.

Syncing with a Pilot on FreeBSD seems to boil down to one of two methods - either pilot-sync or coldsync. JPilot uses the pilot-sync method, so that's the one I concentrated on. Unfortunately, it seems to be the less supported one in the FreeBSD community, so it meant more work. There's a couple of different pages on the pilot-link web site that try to explain how to do this, but in typical fashion, they either don't apply directly to my setup or are incomplete and/or out of date. The README.usb has a FreeBSD section, which talks about how to modify the usbd.conf file. Oddly enough, the author of that section, Anish, replied to me as follows on the questions mailing list:

First you shouldn't be using usbd.conf.  You should be using devd.conf and devfs.rules.

Disable usbd.

Add to devd.conf:
attach 0 {
device-name "ugen[0-9]+";
match "vendor" "0x082d";
match "product" "0x0100";
match "release" "0x0100";
action "/usr/local/sbin/pilot-sync-ugen.sh $device-name";
};

Setup devfs.rules if you have yet to do it:
http://am-productions.biz/docs/devfs.rules.php

Add your user to the operator group or change the mode to 0666 below.
Add to devfs.rules:
add path 'ugen*' group operator
add path 'ugen*' mode 0660

In /usr/local/sbin/pilot-sync-ugen.sh:
#!/bin/sh
#
JPILOT=/usr/X11R6/bin/jpilot-sync
JPILOT_USER=your_username_here
export JPILOT_HOME=/home/$JPILOT_USER
PILOTPORT=usb:/dev/$1
COMMAND=`echo $JPILOT -p $PILOTPORT -b`
# run command ie. (sync)
/usr/bin/su $JPILOT_USER -c "$COMMAND"

Woo boy, a lot of info to digest here! First, he now says to not use usbd and its associated usbd.conf file, and instead use devd.conf. Seems like they both do the same thing, but usbd.conf works only for USB files, while devd.conf works for any run-time devices, like an Ethernet pc-card. I guess maybe the devd.conf is a newer and more generalzied way of dealing with devices, as I'm not sure why to choose one over the other. Here's what I think the lines from Anish means for the /etc/devd.conf lines:

attach 0 {

There's really two basic "actions" you can match in the devd.conf file - attach and detach. The number lets you prioritize the actions, so "attach 0" would happen before "attach 10".

device-name "ugen[0-9]+";

This runs a regexp against the device name being added or removed. If it doesn't match, then the block of statements is ignored. So we're looking for an action on a device called "ugen0" through "ugen9". Which, as the man page for ugen tells us, is a "generic USB" device, and only shows up when you hit the HotSync button on the Palm, something that took a bit to figure out.

match "vendor" "0x082d";

match "product" "0x0100";

match "release" "0x0100";

Now we're doing more matching, because we can't do this on just any ole generic USB device. So we'll check the reported vendor, product and release IDs to see if it matches. These are some magical numbers and, unfortunately, are hard to discover. These ones in particular work for a Visor, but are probably different for all other Palm devices. The easiest way I found to track down these numbers is to run the USB daemon from the command line with the debug option on, and see what it reports:


# killall usbd

# usbd -d -v -v

[bunch o' messages]

[hit the HotSync button]

device-attach event at 1162391812.483582000, Handspring Visor, Handspring Inc:

vndr=0x082d prdct=0x0100 rlse=0x0100 clss=0x0000 subclss=0x0000 prtcl=0x0000

^C

You can see the values listed when the device gets attached. Plug these in for your Palm device.

action "/usr/local/sbin/pilot-sync-ugen.sh $device-name";

};

Now, if all the matches actually are true, we can finally do an action. Here, Anish says to run the shell script we're going to create later and pass it the $device-name, which is a variable that gets set to the match device path (I actually found that documented somewhere, but can't find it at the moment!).

Well, that's a long enough post for now! Suffice to say, we've only just begun our journey of run-time devices, and I still haven't found Palm nirvana yet.