The gnome-pilot code predates HAL, and it feels like much of the functionality ought to be handled at the HAL layer. This bugs is a reminder to me to investigate this at some point
Adding to FC4 Target tracker
I've posted some initial code to the HAL and gnome-pilot mailing lists
gnome-pilot CVS now has some HAL support, which should appear in gnome-pilot-2.0.14.
gnome-pilot-2.0.14 has been out for about 6 weeks now - any chance we'll see this in an FC6 update (or at least rawhide) sometime soon?
Obviously not going to make F7 either. Aside from the fact that a feature freeze is already in effect, I lack the necessary PDA hardware to really even adequately _maintain_ this package. Better to forward this upstream to Matt Davey, I think.
Too bad. Taking this off FC7Target then. We really need to find a better strategy for this bug.
Matthias, I'm not sure I follow your last comment, or why you've taken this off FC7Target. Maybe there's some confusion, either on my part or yours :) gnome-pilot supports HAL since version 2.0.14. I'd recommend FC7 should ship gnome-pilot 2.0.15, which was released last November. It fixes a couple of serious bugs in .14 which crop up on certain devices only. I'd recommend the use of pilot-link 0.12.2. It's a big improvement on 0.11.8, and supports direct libusb syncing which is a lot faster. I'm not sure which evo version you're planning to release, but recent evo releases support pilot-link 0.12.2, include better category support for the conduits, and have e-d-s bugfixes that prevent crashes while syncing (particularly with 'copy-from-palm' mode).
Matt, Matthias was responding to a private comment I made about not making any progress on the feature request for Fedora 7. I've made the comment public. I wasn't aware that gnome-pilot already uses HAL. Rawhide (soon to be Fedora 7) is currently carrying evolution-2.10.1, gnome-pilot-2.0.15 and pilot-link-0.12.1 (wasn't aware of a 0.12.2 release either; I'll upgrade). In your estimation, do you feel this bug has been addressed by recent gnome-pilot releases and can now be closed?
Summary: this bug could be closed, but there is some value leaving it open as there is further gnome-pilot HAL integration that could be done. The integration with HAL means that we no longer poll usbfs in order to detect when a compatible device appeas. Whenever a USB device appears, we check to see if the vendor/device ID pair is a known PalmOS device. If libusb is used, and the udev rule for pilot-link has been installed, too, then the problematic ttyUSBx device is no longer used. Historically, this has been the major hassle for users trying to get devices configured. There are the following caveats: 1. gnome-pilot does not use HAL to identify if a USB device is a PalmOS device. Instead, it looks up the vendor/device ID in the gnome-pilot devices.xml file. I believe this to be more robust. The devices.xml file is easy to edit, and means that if HAL doesn't identify the device we don't prevent syncing. 2. gnome-pilot does not use HAL to identify the ttyUSBx serial device to be used for syncing. I'm not sufficiently convinced HAL support is strong enough in this area -- it's really hard to test, given the proliferation of devices, and would entirely prevent syncing if HAL got it wrong. In any case, we want to migrate away from usbserial and towards libusb sync. 3. There is no real change to the configuration workflow -- e.g. HAL won't start gpilotd when a palm device appears. gpilotd needs to be started by the user running the configuration applet. Basically, I haven't had the time to think about what should happen, or how it should get implemented. We can't just launch the gnome-pilot config applet if gpilotd isn't running, because the user may be using jpilot, kpilot, pilot-xfer, etc. So, I think the current HAL support is probably incomplete, but is definitely useful and improves the behaviour of gpilotd. Used in conjunction with libusb syncing in pilot-link 0.12, it greatly simplifies configuration. It's getting to the stage where FC7 could be configured for libusb syncing instead of usbserial, by default. This would require p-l 0.12, plus blacklisting of the 'visor' usbserial device and installation of an appropriate pilot-link rule. See the pilot-link libusb howto for more info: http://code.pilot-link.org/README.libusb udev rule.
Note that the udev rule is not going to work when we remove pam-console (probably early in the Fedora 8 cycle). I'll follow up with a more thoughtful reply later when that happens. Thanks.
Matt, thanks for following up. Obviously, we were not quite uptodate as to where things currently stand.
Matt, just curious if there's any progress to report here for Fedora 8.
Nothing has changed, but I'm happier about the state of gp/hal integration after a few months soak. This ticket can be closed, as far as I'm concerned. I'm not sure which udev rule David is referring to three comments up. Hopefully the ttyUSB rule, not the libusb rule. At least one distribution (ubuntu gutsy) is shipping with libusb syncing on by default (i.e. visor module blacklisted). This seems to be working well, but note that the pilot-link folks still deem libusb experimental and would rather distribs don't ship it as a default. Might be worth pinging David Desrosiers and asking what would change their mind on this one! My preferred option for gnome-pilot/hal is not to make any improvements to support the visor/usbserial path as it is effectively already legacy mode. The gnome-pilot devices.xml file is working fine and seems stable. Most new devices seem to re-use existing vendor/device IDs as far as I can tell, so there isn't much churn here.
Cool, thanks for the update. I'll close this, then, as CURRENTRELEASE.