I just want to take my hat off to you

You are a genius, or a magician, or both. Many, many thanks,

Chas

by Chas Spencer, 24 Nov 2004

questions about permissions

Hi,

Thanks for your comments.  They definitely clarified things.    I have one question about permissions though.  When I connect the palm, ttyUSB1 gets the permissions 600 instead of 660.  In fact, as far as I can tell, changing the 0660 in the permissions file does not affect that actual assigned permissions.  This isn't really a problem because this gives the local user permissions, but it doesn't seem right.  Have you noticed this problem?

I have also noticed that sync operations with gpilotd get to the cleanup stage but then state that the connection was lost.  I assume this is the silent crash you mentioned in your comments.  This happens with pilot-xfer as well.  Is this the case for you?

By the way, I think the information you have here would be very useful at fedoranews.org.  Have you considered submitting it?

by David Kaplan, 29 Dec 2004

Re: questions about permissions

I played around some more with the udev configuration files. As stated in /usr/share/doc/udev-039/udev.html, the script /etc/dev.d/default/05-pam_console.dev is called for every new device node - presumably after the permissions have been set according to the files in /etc/udev/permissions.d. This script in turn relies on the configuration in /etc/security/console.perms. And in that file, you can find an entry for /dev/pilot. Because we created it as a symlink to ttyUSB1 in our 10-visor.rules file, the owner and permissions for /dev/ttyUSB1 will be changed to the currently logged-in user and 0600.

So in conclusion, we can simply remove /etc/udev/permissions.d/10-visor.permissions and everything will work. If you really need custom permissions for the pilot device file, keep the above udev file, and remove the following line in /etc/security/console.perms:

<console>  0600 <pilot>      0660 root.uucp

The silent crash with newer kernels completely prevents synchronization with gpilotd, ie. gpilotd does not start the synchronziation at all. It does not affect pilot-xfer, if I remember correctly. So the "lost connection" during cleanup must be something else.

Regarding fedoranews.org: Thomas Chung has already added all necessary information to his gnome-pilot tutorial.

by Carsten Clasohm, 29 Dec 2004

Thanx

Thanx for the script and for the udev rule. That rule let me work without settings permissions each time...

I do have a probleme though: pilot-xfer -l seems to work. It prints some things, but seems to alt somewhere and the palm says that the connection was lost with the computer. Here is the pilot-xfer -l ouput:

  No $PILOTPORT specified and no -p port given.
  Defaulting to '/dev/pilot'


  Listening to port: /dev/pilot

  Please press the HotSync button now... Connected

Reading list of databases in RAM...
Queries
AddressDB
DatebookDB
ExpenseDB
locLDefLocationDB
MemoDB
ConnectionMgr50DB
NetworkDB
npadDB
ToDoDB
locLCusLocationDB
locLTimeZoneDB
DynDevInfo-DDIR_appl_a68k
GoLCD-GAny_panl_a68k
Clock-PcLK_appl_a68k
Power_Powr_panl_a68k
Quick Tour_QKTR_appl_a68k

Then it freeze, and I get the connection error on the palm (Palm Zire 21). I never was able to use kpilot... What could be wrong?

Thank you very much!!!

by Big Biggie, 29 Dec 2004

It was a kernel bug...

The sync freezing seems to be a kernel bug. I was using 2.6.9-1.681_FC3 (it was updated from the original 2.6.9-1.667 form the cd installation).
I booted to 2.6.9-1.667 and now everything works great! :)

by Big Biggie, 29 Dec 2004

More on a kernel bur

Thank you revealing the mysteries of udev and also thanks to Big Biggie for your help with the kernel bug. I found that palm syncs no longer freezes up with the the newer kernel 2.6.9-1.724.

by Bruce Bouchard, 09 Jan 2005

Tungsten T5 settings

Great article, thanks for the headstart.

I had to make one change to get it working with my new T5

BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot"

by Michael Hamelin, 22 Jan 2005

Palm Zire (the original) still doesn't work?

I have done everything suggested above, /var/log/messages tells me that the palm is registered, ll /dev/pilot points to the correctly registered ttyUSB (keeps changing). but no connection. pilot-xfer -l nada.

jpilot sync'ed with it TWICE. And TWICE only out of hundreds of tries. So Close, but so far. All Up2Date by 3 Feb. Any ideas?

by Alan Clark, 03 Feb 2005

Treo 650

Doesn't seem to work for a Treo 650, although I could be doing something wrong. Should it work? If not, what do I check? Everything sort of looks right ... I see that product file, and it says "Palm Handheld" (no space in my case, but the * shoudl still be OK, no?), and /dev/ttyUSB[0-3] show up, and /dev/pilot links to /dev/ttyUSB-something. Any ideas? Thanks.

by Matt Morgan, 04 Feb 2005

Treo 650 redux

Nevermind--it works for root. How should I look to fix permissions problems now? From reading the above, I shouldn't have to do anything, but maybe I still do.

by Matt Morgan, 04 Feb 2005

Re: Treo 650

If the symbolic link /dev/pilot is created, the script /etc/dev.d/default/05-pam_console.dev and its configuration /etc/security/console.perms should set the correct ownership and permissions for the device file to which /dev/pilot points.

To get a bit more information about what's happening, you can set udev_log to "yes" in /etc/udev/udev.conf. When you press the HotSync button, you should then see something like this in /var/log/messages:

kernel: usb 3-1: new full speed USB device using ohci_hcd and address 3
kernel: visor 3-1:1.0: Handspring Visor / Palm OS converter detected
kernel: usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB0
kernel: usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB1
udev[9095]: creating device node '/dev/ttyUSB0'
udev[9097]: configured rule in '/etc/udev/rules.d/10-visor.rules' at line 1 applied, added symlink 'pilot'
udev[9097]: creating device node '/dev/ttyUSB1'
05-pam_console.dev[9128]: Restoring console permissions for /dev/ttyUSB0 
05-pam_console.dev[9129]: Restoring console permissions for /dev/ttyUSB1  /dev/pilot

by Carsten Clasohm, 05 Feb 2005

Re: Treo 650

Interesting. I was getting errors that "/" was not owned by root. I fixed that general problem and now I can sync. Thanks!

Is there any solution to the chicken-and-egg problem with /dev/pilot not being there until you start syncing? I have to hit "sync" in J-Pilot (which generates errors), then hit the Hotsync button on the cable, and then hit "sync" again to get anything to happen. Ditto for pilot-xfer, install-user, etc. Not unbearable, but a little unclean.

by Matt Morgan, 07 Feb 2005

Re: Treo 650

For pilot-xfer, there's the little script I included in the blog posting. And when using J-Pilot, I press the Palm's HotSync button first, and then click on Sync or Backup in J-Pilot. Works pretty well.

If the Palm is the only device which creates ttyUSB device nodes on your computer, you can also do the following:

1. Create the device nodes and the pilot symlink in /etc/udev/devices, so they will be copied to /dev when Linux boots. The easiest way to get the nodes and the symlink is to press the HotSync button while no synchronization software is running, and then to copy them with "cp -a ..." If you want to test this without rebooting, don't forget to copy them back from /etc/udev/devices after the Palm has disconnected.
2. Change /etc/udev/rules.d/10-visor.rules so that udev does not touch the Palm ttyUSB device nodes. Otherwise, the nodes from the first step would be deleted each time the Palm disconnects. To do this, replace SYMLINK="pilot" with NAME="disabled". This will actually create a device node called "disabled", but I found no other way to keep udev away from the ttyUSB device nodes.

by Carsten Clasohm, 08 Feb 2005

Re: Treo 650

For what it's worth, if you're interested in syncing Evolution via gpilotd, it seems to help to add the following stanza to /usr/share/gnome-pilot/devices.xml:

<!-- PalmOne -->
<!-- Treo 650 -->
<device vendor_id="0830" product_id="0061" />
I also found that my initial sync only worked when I started gpilotd from the command line, having already set up the config for the pilot correctly in ~/.gnome2/gnome-pilot.d/gpilotd, and *then* pushed the sync button on the treo. Finally it also seems to help to set the timeout value in ~/.gnome2/gnome-pilot.d/gpilotd to a high value (1000).

by Hugh Brock, 16 Feb 2005

This only works for the first sync

Sorry but the original new udev rule doesn't work for me. More exactly it does work but only for the very first sync, and then no more. The /dev/pilot symlink is not created after the first time, the /dev/ttyUSB* does not change permissions.

This udev thing is a complete nightmare. I've been trying to restore my palm for **HOURS** now.

I'm running FC3 with the latest kernel (2.6.10-1.766_FC3) on an Athlon-64.

I'm trying the various hacks posted here one by one and I'm not having fun, this not supposed to be so bloody damn hard.

by hugues Talbot, 20 Feb 2005

Fixed by ignoring udev

I've had no ends of troubles with this. Udev seems very flaky at least for these palm devices. This is running contrary to all expectations I guess, i.e. making things much much harder.

Anyway, here's my desperate solution after a few hours of not being able to sync at all, or only as root,

1- Create the copies of /dev/ttyUSB{0,1} in /etc/udev/devices as per instructions above (press the sync button on the palm, cp -a the devices that show up in /dev, etc)
2- chmod the permissions on these copies to your heart's content
3- set /etc/udev/devices/ttyUSB1 as your $PILOTPORT

You are done. Everything works as before udev.

I can finally sync as a normal user in jpilot, yeah.

NOTE: I've tried everything else before resorting to that, believe me.

by hugues Talbot, 21 Feb 2005

Stating the obvious - for Handspring Visor

I have a Handspring Visor.  Just pointing out one subtle change that may stall someone blindly using the suggested rules above, like I did: you can't do SYSFS{product}="Palm Handheld*" if the product calls itself a "Handspring".  I used Handspring* and it worked just find.

by Clay Juckett, 26 Feb 2005

More generic entry in /etc/udev/rules.d...

Fedoranews.org states to use this:
KERNEL="ttyUSB1",SYMLINK="pilot"

but I had troubles getting /dev/pilot created, so I tried the last entry here with "Handspring" and it worked fine.

I thought if I removed the brand reference, it might work in a more "generic" sense, for any "PalmOS" device.  This line in /etc/udev/rules.d/10-visor.rules works for me:

BUS="usb" KERNEL="ttyUSB*",SYMLINK="pilot"

I have an old Handspring Visor Platinum, so your mileage may vary with Palm OS5 devices.

by Bob Recny, 28 Feb 2005

No luck with a Tapwave Zodiac

I have a Tapwave Zodiac 2, and can't get anywhere with USB connection on linux (FC3, up to date).

lsusb identifies it as:

  idVendor          0x12ef
  idProduct          0x0100
  bcdDevice            1.00
  iManufacturer          1 Tapwave, Inc.
  iProduct                2 Tapwave Handheld
  iSerial                5 Tapwave0001

So I added the following to /etc/udev/rules.d/10-visor.rule:

BUS="usb", SYSFS{product}="Tapwave Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot"

After connecting and hitting Sync, I see this in /var/log/messages:

Mar  9 17:42:39 sillysailor kernel: usb 1-1: new full speed USB device using uhci_hcd and address 17

And that's it.  This is with or without the visor module loaded.  I'm running kernel 2.6.10-1.770_FC3.  I also tried taking out the product stuff from the udev rule, and that didn't help.

by n s, 10 Mar 2005

Cheers!

Syncing with a Treo 600. Works fine so far.

Thanks!

by pradeep jey, 13 Mar 2005

Tungsten E with 2.6.10-1.770_FC3

Syncs intermittently, using two different systems with the
same kernel.  When it works, /dev/pilot is linked to ttyUSB1:

$ ls -lZ /dev/ttyUSB? /dev/pilot
lrwxrwxrwx  root    root    system_u:object_r:device_t      /dev/pilot -> ttyUSB1
crw-------  gwhite  uucp    system_u:object_r:tty_device_t  /dev/ttyUSB0
crw-------  gwhite  uucp    system_u:object_r:tty_device_t  /dev/ttyUSB1

Sometimes the Palm uses ttyUSB 2 and 3, but /dev/pilot is linked to /dev/ttyUSB2.  I think it should use ttyUSB3.

by George White, 13 Mar 2005

Thank you Bob

My Palm devce is T3. I have spent days trying the above recommended configurations till I read Bob's message. I tried it and it worked in a second. Thanks a lot Bob.

by Abdullah alfadhly, 28 Mar 2005

Instructions for Abacus/Fossil Palm Watch

Get the necessary information especially the vendor and product ID from Linux.
Perform a Hotsync on the Palm Watch and issue a lsusb command during the Hotsync.

# lsusb -v

Bus 002 Device 002: ID 0e67:0002
Device Descriptor:
  bLength                18
  bDescriptorType        1
  bcdUSB              1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass        0
  bDeviceProtocol        0
  bMaxPacketSize0        8
  idVendor          0x0e67
  idProduct          0x0002
  bcdDevice            0.01
  iManufacturer          1 Fossil, Inc.
  iProduct                2 Wrist PDA
  iSerial                0


Create /etc/udev/rules.d/10-visor.rules the following information:
    BUS="usb", SYSFS{product}="Wrist PDA*", KERNEL="ttyUSB*", SYMLINK="pilot"

To make the Hotsync work for the Palm Watch, issue the following command.
# /sbin/modprobe visor vendor=0xe67 product=0x2

Add the following to /etc/rc.d/rc.local so it will initialize visor module with
the correct vendor and product ID for the Palm Watch after rebooting:
    /sbin/modprobe visor vendor=0xe67 product=0x2

Ed
email: edjge at yahoo.com

by E J, 25 Apr 2005

Thanks!

Thanks a lot for writing this - you would never guess how much email I get asking how rules can be written for Palm Pilot devices. I've adapted your rule and linked to here in the latest version of Writing udev rules (http://www.reactivated.net/writing_udev_rules.html) which is about to be published.

-- Daniel Drake

by Daniel Drake, 10 May 2005

Something that helped me sync my Palm Tungsten T5

Please note that this is just for Palm T5's.  It probably just applies to T5's.

I am a Palm Tungsten T5 owner.  When my pilot connects via USB, the linux kernel creates devices: ttyUSB0 and ttyUSB1 (or ttyUSB2,ttyUSB3 and so forth).  Always an even and an odd number, but any side of the spectrum.  The syncable ttyUSB? is always the latter of the two, which is my case is an odd number.  For example, if ttyUSB2 and ttyUSB3, then the device to use would be ttyUSB3, and not ttyUSB2.

The problem I had was with the rule:
BUS="usb", SYSFS{product}="palmOne Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot"
is that sometimes /dev/pilot would be matched to the even number (ttyUSB0,2,4) and sometimes the odd number (ttyUSB1,3,5,etc).  So, my hotsyncs would only work half of the time (when matched to the odd number).

To compensate, I changed the ttyUSB* to ttyUSB[13579], so it would always match the odd numbered USB connection.  So far, its been consistent, and my syncs are working much more reliably when I press the button.  Its quite a hack... but, well, I think that's why linux is so great.  Linux hacks are kind of like duct tape.

If you already have a ttyUSB? device, it may cause your pilot to come in as odd/even numbers.  You may have to change it to match even numbers, if you are in the same boat as I am.

One other thing that helps, is I turn off my palm pilot before plugging it in the usb cable.  Then I push the hotsync button.  This keeps it kpilotdaemon from connecting to the non-hotsyncable usb device that shows up when the palm pilot is simply on.

Does anybody know a better way to do this?  Can you enlighten me in my ways?

by Tim Harper, 03 Jun 2005

Solutions with a Palm Tungsten E

I had all of the troubles show above.  The solutions were BUS="usb", KERNEL="ttyUSB[13579]", SYMLINK="pilot" and realizing that after the first two successful syncs the rest would fail with "khubd" giving an error message in /var/log/messages.  I had my USB cable hooked to a hub external to my computer.  Moving the cable from the hub to connecting directly to the computer solved everything.  Thanks Bob Laughlin

by Robert Laughlin, 11 Jun 2005

Syncing perfectly on Fedora 3 with Zire 31

The things I needed to get syncing working properly with my Zire 31 were to:

1) add the /etc/udev/rules.d/10-visor.rules exactly as specified at the top of this post;

2) add an entry to /usr/share/gnome-pilot/devices.xml as per Hugh Brock's post of 16 Feb 2005;

3) implement the script ~/bin/mypilot-xfer:

#!/bin/sh
# used because I sync w/Evo using gnome-pilot applet 2.0.12

echo -n "Did you pause gpilotd? (y/N): "
read checkvar
if [ $checkvar = "y" -o $checkvar = "Y" ]
then
    echo "Press HotSync to establish the connection."
    until [ -e /dev/pilot ]; do sleep 1; done
    exec /usr/bin/pilot-xfer "$@"
else
    echo "Exiting..."
    exit 1
fi

4) to simplify back-up syncing I implemented ~/bin/pilot-sync:

#!/bin/sh
PILOT="/usr/bin/pilot-xfer -p /dev/pilot"
MEMOS="/usr/bin/memos -p /dev/pilot"
DIR=$HOME/new-pilot

echo -n "Did you pause gpilotd? (y/N): "
read checkvar
if [ $checkvar = "y" -o $checkvar = "Y" ]
then
    echo "Press HotSync to establish the connection."
    until [ -e /dev/pilot ]; do sleep 1; done
    echo "Retrieving text copies of memos to $DIR/backup/memos..."
    find $DIR/backup/memos -type f -exec rm {} \;
    $MEMOS -s $DIR/backup/memos
    sleep 5
    echo "Press HotSync to reestablish the connection."
    until [ -e /dev/pilot ]; do sleep 1; done
    echo "Synchronizing pilot to $DIR/backup..."
    exec $PILOT -e $DIR/excludes -s $DIR/backup
else
    echo "Exiting..."
    exit 1
fi

Thanks for all the help! Bill Barnard

by Bill Barnard, 24 Jun 2005

Help with UDEV rule - no /dev/pilot created

I'm having trouble with my Handspring Visor and FC3.  It seems that the udev system isn't processing my rules in /etc/udev/rules.d/10-local.rules and therefore not creating symlinks from /dev/ttyUSB* to /dev/pilot.

Here's what I see if I say dmesg after pressing the hotsync button:

-----
usb 3-2: new full speed USB device using uhci_hcd and address 33
usb 3-2: Handspring Visor / Palm OS: port 1, is for Generic use
usb 3-2: Handspring Visor / Palm OS: port 2, is for HotSync use
usb 3-2: Handspring Visor / Palm OS: Number of ports: 2
visor 3-2:1.0: Handspring Visor / Palm OS converter detected
usb 3-2: Handspring Visor / Palm OS converter now attached to ttyUSB0
usb 3-2: Handspring Visor / Palm OS converter now attached to ttyUSB1
usb 3-2: USB disconnect, address 33
visor ttyUSB0: Handspring Visor / Palm OS converter now disconnected from ttyUSB0
visor ttyUSB1: Handspring Visor / Palm OS converter now disconnected from ttyUSB1
visor 3-2:1.0: device disconnected
-----

Here's my 10-local.rules file:

-----
BUS="usb", SYSFS{product}="Handspring*", KERNEL="ttyUSB*", SYMLINK="pilot", MODE="660"
-----

Here's (part of) /proc/bus/usb/devices, while the Handspring is actually connected:

-----
T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=16 #Cfgs=  1
P:  Vendor=082d ProdID=0100 Rev= 1.00
S:  Manufacturer=Handspring Inc
S:  Product=Handspring Visor
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=visor
E:  Ad=81(I) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
-----

I'm stuck!  The udev system clearly "sees" the Handspring, but the log doesn't say anything like "udev[9097]: configured rule in '/etc/udev/rules.d/10-visor.rules' at line 1 applied, added symlink 'pilot'" (reference the February 2005 post including a log file above).

Any help is appreciated.

by Clay Juckett, 24 Jul 2005

Helps in Ubuntu, too!

Carsten, Thanks again for this little guide. I'm trying out Ubuntu now, and the udev trick works nicely (to get /dev/pilot working) in Ubuntu as well.

by Matt Morgan, 27 Sep 2005

FC4 can NOT use CardExport with Palm TE!

I can *NOT* use CardExport with my Palm TE on FC4. And the sync function with pilot-link is wonderful.

by Allen Chen, 10 Oct 2005

solution for FC4, kernel 2.6.15 & udev 0.71

Hi,

First of all -- thanks for your guide. It worked perfectly until I've upgraded my system to kernel-2.6.15-1.1830_FC4 and udev-071-0.FC4.2. With the new configuration I was only able to sync as a root.

After 3 hours of playing I've found out that you have to change (revert) the contents of the file /etc/udev/rules.d/50-udev.rules
Find the line with:

KERNEL=="ttyUSB*",            GROUP="uucp", MODE="0660", OPTIONS="last_rule"

and remove the option, so the line becomes:

KERNEL=="ttyUSB*",              GROUP="uucp", MODE="0660"

I'm not sure why, but it works :)

by Michal Oledzki, 04 Feb 2006

Re: solution for FC4, kernel 2.6.15 & udev 0.71

I experienced the same thing after upgrading to udev-071. According to the udev man page, the last_rule option prevents any other rules to be executed for the matched devices, so no pilot link is created, and permissions are not set.

Thanks for posting the solution!

by Carsten Clasohm, 04 Feb 2006

Palm M130 is on ttyUSB0

I followed the instructions and saw the creation of the /dev/pilot pointing at /dev/ttyUSB1 but pilot-xfer failed to bind on /dev/pilot.

After experimenting, I found that changing the 10-visor.rules line to included KERNEL="ttyUSB0" pointed /dev/pilot at /dev/ttyUSB0 and pilot-xfer works just fine now!

Thanks for the page.  My wife will be happy that she can sync now!

by Alan Dayley, 31 Mar 2006

Palm Z22 is on ttyUSB1

As the end to my story, the purpose of finaly getting the sync working was to allow data transfer from the M130 to my wife's new Z22.  To get the Z22 to work, I had to point /dev/pilot back at /dev/ttyUSB1.  [shrug]

Final tidbits about the Z22

- As soon as you plug the Z22 into the USB, udev creates the /dev/ttyUSB* and /dev/pilot entries.  They are already there before you trigger the sync on the Z22.

- Someone (the Z22 or udev or ??) seems to take a bit longer with the the Z22 when you trigger the sync on the device, even though the /dev/ttyUSB* and /dev/pilot are already there.  Syncing to jpilot required that we trigger the sync on the Z22, wait 5-10 seconds and then click the Sync button in jpilot.

Hope that helps someone.

by Alan Dayley, 31 Mar 2006

pilot id not matching

I've got a strange problem, but first let me say that following the various tip found on this site, allowed my box to see my treo, but here is my problem, everytime I go to sync my treo now that it is set up I get an error saying that my pilot's ID doesn't match.  Then when I enter it, it gets set to a large negative number since the ID returned from the palm is to big.... any ideas????
Thanks

by nick carrasco, 23 Aug 2006

"Permission denied" even after I use "chmod 666 ttyUSB1", TT5

I am a TT5 owner and using JPilot for sync. But I can't handle the permission problem at all. It shows "Permission denied" even after I use "chmod 666 ttyUSB1".

by Anonymous Visitor, 11 Apr 2007

Re: "Permission denied" even after I use "chmod 666 ttyUSB1", TT5

The entries in /dev are recreated every time you press the Hotsync button. Running chmod on these entries may work if you are fast enough. For a more reliable way to use chmod, see the comment titled "Fixed by ignoring udev".

by Carsten Clasohm, 11 Apr 2007

Thanks - it works; but why?

Thanks for this; I just don't understand why

BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB[13579]", SYMLINK="pilot"

actually works, since every operator is an "assignment" operator and there is no "matching" operator.  Even in Daniel Drake's article on writing udev rules, he says, << Carsten's rule is shown below:

    BUS=="usb", SYSFS{product}=="Palm Handheld", KERNEL=="ttyUSB*", SYMLINK+="pilot" >>

which would seem to be correct according to udev rules as he explains them.

I would just like to say I understand this.

Thanks,

Jim

by Anonymous Visitor, 17 Jun 2007

Re: Thanks - it works; but why?

You are right, the operators were wrong. I have fixed this in the blog entry. And I have successfully tested it with Fedora 7, where the custom udev rule is still required.

I guess that the old rule worked because udev knows that it cannot assign anything to "BUS" or "SYSFS", and silently replaces the operators.

by Carsten Clasohm, 17 Jun 2007

How I got it to work with FC 7

I noticed that the kernel was not producing /dev/ttyUSB* devices but rather /dev/usbdev1.*_ep00 etc devices.  I changed the 10-visor.rules entry to the following and jpilot now works under FC7

BUS=="usb", SYSFS{product}=="Palm Handheld", KERNEL=="usbdev1.*", SYMLINK="pilot", GROUP="usb", MODE="0666"

by Anonymous Visitor, 25 Jun 2007

Initial Sync on FC7 with Tungsten E failing

I created /etc/udev/rules.d/10-visor.rules containing:

BUS=="usb", SYSFS{product}=="Palm Handheld", KERNEL=="usbdev1.*", SYMLINK+="pilot", MODE="0666"

It creates /dev/pilot pointing to /dev/usbdev1.13_ep82 owned by the user.  The command /sbin/lsusb list a "Palm Tungsten" device.  However, the initial sync of gnome-pilot under evolution just times out and never connects.  /usr/bin/pilot-debugsh says "unable to connect".

by Anonymous Visitor, 05 Aug 2007

Rule didn't work on Gentoo with UDev 114

Some of the key names have changed since the last version of udev reported to work with this rule. My 50-udev.rules (by default) contains:

KERNEL=="ttyUSB[0-9]*",    NAME="%k", SYMLINK="tts/USB%n", GROUP="uucp", MODE="0660"

My system doesn't use console.perms or permissions.d. Here is the rule that worked for me (in 10-visor.rules):

SUBSYSTEMS=="usb", ATTRS{product}=="Palm Handheld", KERNEL=="ttyUSB[13579]", NAME="%k", SYMLINK="pilot tts/USB%n", GROUP="plugdev", MODE="0660"

This creates ttyUSB{odd number} along with /dev/pilot and /dev/tts/USB{odd number} with plugdev group permissions. 50-udev.rules is ignored if this rule is active. However, 50-udev.rules applies for everything else (including ttyUSB0)

by Anonymous Visitor, 24 Aug 2007

Additional step needed

the above rules work fine for Fedora 7, after you have loaded
"libopensync-plugin-palm".  That lib is needed to get the
Visor stuff to work.  Oh and the double = signs where shown
and the += in the SYMLINK item.

Bob Laughlin

by Anonymous Visitor, 27 Aug 2007

USB Palm Zire with FC7

Hi,

I read and tried everything listed above, with no result.
I see a /dev/ttyUSB1 file when I try to sync with the gnome-pilot settings tool, but nothing hapens.
How do I setup that 10-visor.rules file?
What else do I have to do?
What else is needed?

Thanks,

Jacques Fournier

by Jacques Fournier, 16 Sep 2007

USB Palm Tungsten E2 and FC7

I just had a problem with and E2 and FC7, all updates.  I got the following message(s); device not accepting address 50, error -62.  This appeared many times.  I have had the E2 and FC7 working before.  One of the news groups left me with a clue.  I had not had to reboot since the middle of August.  Maybe something in the kernel had filled up.  After rebooting it all worked to gather.  I have a couple of entries above that solved most problems.
Bob Laughlin

by Anonymous Visitor, 24 Nov 2007

Treo 700p acts like the Tungsten T5

The udev rule works for me only sometimes.  It appears that /dev/pilot get symlinked to /dev/ttyUSB1 and thats great but then the next time I sync (minutes later), the palm is linked to ttyUSB3 but I can't sync because /dev/pilot is still linked to /dev/ttyUSB1/.

Is there a way for /dev/pilot to see the change and update the symbolic link to point to the correct ttyUSB# as it changes?

I look forward to the hack!

~trode

by Anonymous Visitor, 01 Dec 2007

Visor Platinum

Thanks for that.

For my Visor Platinum I had to change the string to:

BUS=="usb", SYSFS{product}=="Handspring Visor", KERNEL=="ttyUSB[13579]", SYMLINK+="pilot"

I haven't gone beyond that yet but thanks very much!

Lee

by Anonymous Visitor, 06 Dec 2007

Why are multiple device files created for one Treo 650 device on F7?

I'm trying to figure out why the visor module (or udev, can't tell
which) creates two device files, one for /dev/ttyUSB0, and
the other /dev/ttyUSB1 when I hit the hotsync button on my Treo
650.

This is on F7 (Fedora 7). The relevant /var/log/messages output is:

Jan  6 13:31:42 hungover kernel: visor 1-4:1.0: Handspring Visor / Palm OS converter detected
Jan  6 13:31:42 hungover kernel: usb 1-4: Handspring Visor / Palm OS converter now attached to ttyUSB0
Jan  6 13:31:42 hungover kernel: usb 1-4: Handspring Visor / Palm OS converter now attached to ttyUSB1

The udev rules that I am using is in /etc/udev/rules.d/10-custom.rules
which reads:

BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666", OPTIONS+="last_rule"

I will be using NAME="ttyUSB[13579]" eventually, but I want to
know why multiple devices being created.

BG

by B G, 07 Jan 2008

Palm Tungsten E2

Hi!

After reading your side about udev, I tried to get my Palm
and jpilot to sync without using the sync-Button in JPilot
but just by pressing the hotsync button on the cradle.
This is the line in /etc/udev/rules.d/udev.rules that made it work on my
system:

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
ATTRS{product}=="Palm Handheld*|Handspring Visor|palmOne Handheld", \
SYMLINK+="pilot" RUN="/bin/su -l michael -c '/usr/bin/jpilot -s'"

My name must be replaced by the appropriate user name of course.

My system is a Debian stable with kernel 2.6.18-6-k7.

Greetings from Sweden

//M

by Anonymous Visitor, 25 Jan 2009

How do I show the palm using udevinfo

My udev rule works fine, but how can I get udevinfo to show the detail of my device?

by Anonymous Visitor, 26 Feb 2010

Palm tungsten not creating ttyUSB but is creating /dev/pilot

On Fedora12 I have to remove KERNEL=="ttyUSB" and then mine works.  So if its not ttyUSB what is it???

by Anonymous Visitor, 26 Feb 2010

Fedora 15 Palm Tx sync failure

I updated to F15 and jPilot worked fine.  After one of the updates syncing stopped working.  I just found out the the visor modules were not loaded for some reason.  Running "modprobe visor" corrected the problem.
Bob Laughlin

by Anonymous Visitor, 22 Aug 2011

OOPS Blacklist

Yesterday I posted that, with Fedora 15, my Palm Tx suddenly would not sync.  I was able to get it to work after "modprobe visor".  Upon rebooting it still would not work.  Then I found that in /etc/modprobe.d a file "blacklist-visor.conf" had been created.  That stopped the visor driver from being loaded the first time that the Palm Tx was connected.  OOPS.  I do not know where that file came from.  Removing it fixed the problem.

by Anonymous Visitor, 23 Aug 2011

Comments are reviewed before they appear on this page.

Title:

Comment:

Text above is Plain Text HTML