Announcement

Collapse
No announcement yet.

[gjk]pilot no longer working - libusb but no visor; not 'plug & play'

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

    Are there instructions for getting my Palm Lifedrive to connect under Feisty?

    One of the Xpilot programs notes visor is no longer in kernel, so use usb:, but still no connection.

    Some sort of heads up in this regard needs to be present as part of upgrade process. Including a link to 'how to connect your pilot under feisty' sort of thing.

    In the meantime ... what do I now need to do to get my Palm to connect under Feisty?

    #2
    Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

    This issue has affected me to. After so long of being unable to get my PDA to sync under Edgy, it was nice to have it sync under Feisty. Now it no longer does. I'm using a Sony Clie NX80.

    Comment


      #3
      Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

      Actually ... I got them to run, now. After a day at the #pilot-link irc.

      visor is present, it's just blacklisted (if I remember correctly). At the moment I can't recall where the file is. /etc/udev/rules.d/{something} ?

      And the 60-symlink (?!?) file in /etc/{somewhere else} is incorrect. pilot-link.org has the correct one somewhere ... except ... where it says {Palm Handheld*|Handspring *} or something like that, it also needs to add 'PalmOne Handheld*'. At least for my LifeDrive.

      Having said that:
      - gpilotd (gnome-pilot) croaks mid-way through sync.
      - jpilot croaks mid-way through in todo.c
      - kpilot loses your events and tasks. [This happened to me twice, once under Edgy when I was trying to figure things out and didn't notice until AFTER I sync'ed to Windows!, and again under Feisty when testing.]

      I investigated Feisty, and it came through for me, running 12.2 of pilot-link, latest, and 3.5.6 kpilot, both much better than Edgy. So pilot-link is happy, now, it's the other software that's broken. And it's latest, so I don't expect the problems to ever get fixed. At least for the LifeDrive.

      Which is all to say ... if a major reason for using a computer is PIM / e-mail / whatever, well ... GNU/Linux isn't going to be that computer.

      Having said that ... there are too many messages saying this all just works for me not to believe the problem is not the Palm LifeDrive. So the above may only be true until I get a different Palm.

      Comment


        #4
        Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

        I'm back at that machine now, I'll be more specific:

        Actually ... I got them to run, now. After a day at the #pilot-link irc.

        visor is present, it's just blacklisted (if I remember correctly).
        In /etc/modprobe.d/libpisock9, you'll see '#blacklist visor'. Remove the '#'. (Nothing else to do here.)

        And the 60-symlink (?!?) file in /etc/{somewhere else} is incorrect.
        In /etc/udev/rules.d/60-symlinks.rules is a line (spread over 3, actually) talking about the pilot. Replace that line with: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *|PalmOne Handheld*", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666"

        Then restart udev by running: /etc/init.d/udev restart

        Sorry, I don't have the old one to show any more, but it started the same, had a blank line I believe, then the 3rd started quite far in, ending approximately the same way.

        BTW - the usbview program was incredibly useful here ... if only to physically show you that yes, the Palm is indeed plugged in. i.e. There's no physical hardware / connectivity issue going on - it's all software.

        Comment


          #5
          Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

          I appreciate your efforts to help us with what seems to me should be a simpler operation.

          Originally posted by bswitzer
          In /etc/modprobe.d/libpisock9, you'll see '#blacklist visor'. Remove the '#'. (Nothing else to do here.)
          That line was uncommented on my system, so I left it alone.

          In /etc/udev/rules.d/60-symlinks.rules is a line (spread over 3, actually) talking about the pilot. Replace that line with: BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *|PalmOne Handheld*", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666"

          Then restart udev by running: /etc/init.d/udev restart

          BTW - the usbview program was incredibly useful here ... if only to physically show you that yes, the Palm is indeed plugged in. i.e. There's no physical hardware / connectivity issue going on - it's all software.
          I did all of the above, and usbview did indeed show that the Palm Tungsten C was connecting. But Konqueror did not show either /dev/pilot or /dev/ttyUSBx (I have 4) showing up during the Palm's attempt to sync and a Konqueror refresh.

          Any other ideas?

          Lane
          Lane Lester
          The Web Doctor

          Comment


            #6
            Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

            Originally posted by LaneLester
            I appreciate your efforts to help us with what seems to me should be a simpler operation.
            Yes, well ... I don't disagree. All I can say, being new to the @buntus / Linux as well, it is the way it is. Windows, when it comes to hardware, does seem to have the advantage of not only being master of its own (USB) hardware, device manufacturers make Windows drivers, while Linux has to take best guesses based upon observed behaviour.

            They say manufacturers are getting better at providing native Linux drivers.

            Originally posted by bswitzer
            In /etc/modprobe.d/libpisock9, you'll see '#blacklist visor'. Remove the '#'. (Nothing else to do here.)
            That line was uncommented on my system, so I left it alone.
            Ah shoot. Looks like I said this backwards. You want visor to NOT be blacklisted. So it should be commented out. Sorry. Please try again.

            I did all of the above, and usbview did indeed show that the Palm Tungsten C was connecting. But Konqueror did not show either /dev/pilot or /dev/ttyUSBx (I have 4) showing up during the Palm's attempt to sync and a Konqueror refresh.
            You may be falling into the trap of the dis/appearing ports. And /dev/pilot doesn't exist. Without you taking special action to make it appear. So forget it for the moment. Concentrate on /dev/ttyUSB*.

            [The easiest way to watch this stuff is to start a terminal. Use 'ls /dev/ttyUSB*;ls /dev/pilot' as a command line. Press up arrow then enter to repeat. When all done, type 'exit' to close.]

            It appears the Palm only registers as a port when it's sync'ing. So do the line above without doing anything, and you should see blank lines. i.e. No devices.

            From what you've said, you probably have one now. You might want to disconnect it for the purposes of these tests.

            Once sorted out ... press sync on the Palm and run the line above. You will probably see /dev/ttyUSB0 and /dev/ttyUSB1 appear.

            If you already have kpilot up in another window, ready to be configured, you should now be able to use the wizard to detect your device. Note - the point here is that you've pressed sync before pressing anything in buntu.

            I have experienced the reverse, started the detect for /dev/ttyUSB0, kpilot opens up USB0 and USB1, you start the sync., and all of a sudden you have USB2 and USB3 show up. Which kpilot will never detect because it's looking at 0.

            From the pilot-link developer ... always hit sync first, then the program. From my experience, this is true while just trying to get things to work the first time. Once you know / how they're supposed to work, kpilot and the others seem to go into a polling mode wherein they just find things properly. Just not the first time while you sort things out.

            Notes:
            - since you have another device, you may get into a situation (for all I know) where the Palm, for example, is not always /dev/ttyUSB0. Which means you will have to repeatedly change which device to use in settings. If you know the USB device will always be there, for example if it's an external burner, then you're probably ok, just set kpilot to use /dev/ttyUSB2. If you can't say it will always be there, you may be best to only have the Palm connected when you try to sync.

            - to get /dev/pilot, open a terminal, enter 'su -' at the command line and enter your password to become root. Then, when the sync button has been pressed and /dev/ttyUSB0 shows up, do 'ln -s /dev/pilot /dev/ttyUSB0'. This creates a symbolic link between the name /dev/pilot and where it really is.
            (I trust other readers will chime in if I have the order of arguments backwards, or a different type of link than a symbolic one is more appropriate.)

            Comment


              #7
              Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

              Originally posted by bswitzer
              Ah shoot. Looks like I said this backwards. You want visor to NOT be blacklisted. So it should be commented out. Sorry. Please try again.
              I did and followed your other suggestions and was successful! So thank you very much for your help.

              I had just gotten through with similar problems getting kmobiletools and moto4lin to connect to my cell phone. A user there suggested using "dmesg | tail" to detect the port name. So I used it on the Palm and found it at /dev/ttyUSB1. The keyboard's on ttyUSB0, and the Palm's dock is always connected. So the number should stay the same for the Palm.

              Lane
              Lane Lester
              The Web Doctor

              Comment


                #8
                Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

                Originally posted by LaneLester
                I did and followed your other suggestions and was successful! So thank you very much for your help.

                I had just gotten through with similar problems getting kmobiletools and moto4lin to connect to my cell phone. A user there suggested using "dmesg | tail" to detect the port name. So I used it on the Palm and found it at /dev/ttyUSB1. The keyboard's on ttyUSB0, and the Palm's dock is always connected. So the number should stay the same for the Palm.

                Lane
                Great!

                Note that your Palm docked without your Palm is the same as the dock not connected!

                Thanks for the heads up on kmobiletools and moto4lin, I hadn't gotten that far yet.

                "dmesg | tail" - yes. I think you can just do dmesg. Which is the same as "tail /var/log/messages". Or pretty close, anyways.

                Comment


                  #9
                  Re: [gjk]pilot no longer working - libusb but no visor; not 'plug & play'

                  Originally posted by LaneLester
                  Originally posted by bswitzer
                  Ah shoot. Looks like I said this backwards. You want visor to NOT be blacklisted. So it should be commented out. Sorry. Please try again.
                  I did and followed your other suggestions and was successful! So thank you very much for your help.

                  I had just gotten through with similar problems getting kmobiletools and moto4lin to connect to my cell phone. A user there suggested using "dmesg | tail" to detect the port name. So I used it on the Palm and found it at /dev/ttyUSB1. The keyboard's on ttyUSB0, and the Palm's dock is always connected. So the number should stay the same for the Palm.

                  Lane
                  I did as instructed above and my Tungsten T2 is working properly, FYI

                  Regards,

                  MepisReign
                  Beware the Almighty Command Line

                  Comment

                  Working...
                  X