On 07/17/2007 07:59 PM, Craig White wrote: > On Tue, 2007-07-17 at 10:46 -0700, Srikanth Konjarla wrote: >> Craig White wrote: >>> On Tue, 2007-07-17 at 10:23 -0700, Srikanth Konjarla wrote: >>>> Craig White wrote: >>>>> On Mon, 2007-07-16 at 15:13 -0500, Mikkel L. Ellertson wrote: >>>>>> Craig White wrote: >>>>>>> I am struggling trying to make a Palm T|X work on Fedora 7 >>>>>>> >>>>>>> The problem *may* lie with the fact that in order to make this box work >>>>>>> (A Dell Optiplex 320), that I have to add 'pci=nomsi acpi=off' kernel >>>>>>> params on bootup. >>>>>>> >>>>>>> udevinfo tells me all about the device. >>>>>>> >>>>>>> I can see the device exists when I plug it in and check it via >>>>>>> >>>>>>> ls -l /dev/ttyUSB* and >>>>>>> ls -l /dev/pilot >>>>>>> >>>>>>> but even if I try (as root), >>>>>>> >>>>>>> pilot-xfer -l -p /dev/ttyUSB1 or pilot-xfer -l -p /dev/pilot show >>>>>>> nothing at all >>>>>>> >>>>>>> Is the problem my kernel parameters? >>>>>>> >>>>>> It probably isn't your kernel parameters. If it were, then >>>>>> /dev/ttyUSB0 and /dev/USB1 most likely not be created. What happens >>>>>> if you use /dev/ttyUSB0? Or, if you have more then 2 ttyUSB* >>>>>> entries, try using /dev/ttyUSB2. I don't remember if the T|X uses >>>>>> the first or second USB serial port that is created when you hit sync... >>>>> ---- >>>>> OK - didn't know the impact of the kernel params >>>>> >>>>> # ls -l /dev/ttyUSB* >>>>> crw-rw---- 1 root uucp 188, 0 2007-07-17 09:52 /dev/ttyUSB0 >>>>> crw-rw---- 1 root uucp 188, 1 2007-07-17 09:52 /dev/ttyUSB1 >>>>> >>>>> and from dmesg... >>>>> usb 4-2: new full speed USB device using ohci_hcd and address 6 >>>>> usb 4-2: configuration #1 chosen from 1 choice >>>>> visor 4-2:1.0: Handspring Visor / Palm OS converter detected >>>>> usb 4-2: Handspring Visor / Palm OS converter now attached to ttyUSB0 >>>>> usb 4-2: Handspring Visor / Palm OS converter now attached to ttyUSB1 >>>>> >>>>> but while the palm is using ttyUSB0/1 - I get nada... >>>>> >>>>> # pilot-xfer -l -p /dev/ttyUSB1 >>>>> >>>>> Listening for incoming connection on /dev/ttyUSB1... >>>>> >>>>> # pilot-xfer -l -p /dev/ttyUSB0 >>>>> >>>>> Listening for incoming connection on /dev/ttyUSB0... >>>>> # >>>>> >>>>> but never anything else ;-( >>>> As you can see the device files are owned and writable by only root. >>>> There are couple of options that you can try, >>>> >>>> 1. change the permissions on device files as root. >>>> # chmod 777 /dev/ttyUSB* >>>> >>>> Try to sync your palm. >>> ---- >>> you might note the "#" cli prompt which is typical for user root. >>> >>> Trying to sync the palm is rather pointless if you can't do a basic >>> listing of the files on the palm from the pilot-xfer (pilot-link >>> package) which is the base package that all of the GUI tools >>> (JPilot/KPilot/GPilot) all use. >>> ---- >>>> 2. Review the udev rules for ttyUSB* under /etc/udev/rules.d. It is very >>>> likely that the default mode is set to "0660". You can refer to >>>> 50-udev.rules file. Here is a link from one of the old RH Magazines. >>>> >>>> http://www.redhat.com/magazine/002dec04/features/udev/ >>> ---- >>> I am all over the udev rules - I am a long time palm user but that is >>> more for 'users' and I am simply trying to communicate with the palm via >>> pilot-xfer which as stated above, is the basic toolset for accessing a >>> palm. The udev rules are tilted towards user space and again, I am >>> trying to work this through as root first. >>> >>> I am quite certain that this would work with FC-6 but that isn't the >>> point...there is an issue with F7 and it would help if someone related >>> what they have done to get a Palm working on F7 - especially one of the >>> newer 'OS5' Palms >>> >> For whatever it is worth, i have added the following lines to >> 50-udev.rules on F7 to get the palm sync work with jpilot (the palm >> device is configured as /dev/ttyUSB0). I have found that this is missing >> in F7 from that of FC6 (of course i had to change the MODE to 0777). >> >> KERNEL=="ttyUSB*", SYSFS{product}=="Palm Handheld*", SYMLINK+="pilot", >> GROUP="uucp", MODE="0777" >> KERNEL=="ttyUSB*", SYSFS{product}=="palmOne Handheld*", >> SYMLINK+="pilot", GROUP="uucp", MODE="0777" >> KERNEL=="ttyUSB*", SYSFS{product}=="Handspring Visor*", >> SYMLINK+="pilot", GROUP="uucp", MODE="0777" > ---- > thanks - I already have the same thing except MODE="0666" (files not > folders) but that is for user space and I can't get root to be able to > talk to the palm device other than, per my original post, udevinfo can > get the information from the palm but pilot-xfer/pilot-link cannot. > > I am reasonably certain that this issue is related to the newest palm > devices with what they call 'lifedrive' > > http://www.pilot-link.org/node/253 I have a T|X which I backup on my F7 laptop (Dell Inspiron 8200). It is relatively painless, but not completely. I have the following udev rule (I have a lot more, derived from, but not identical to, the ones in /usr/share/pilot-link/udev/60-libpisock.rules): KERNEL=="ttyUSB*", SYSFS{idVendor}=="0830", SYSFS{idProduct}=="0061", SYMLINK+="pilot", GROUP="uucp", MODE="0664" With this rule, there is a shortish window of opportunity to start pilot-xfer after I push the hotsync button on the Palm side. If I am too fast (or start it before I push the button), it doesn't work, and if I am too late, it just hangs. I use /dev/pilot which is created (by udev) as a symlink to /dev/ttyUSB1 (i.e. not /dev/ttyUSB0). -- Sjoerd Mullender
