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
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
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
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,
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:
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.