Bug 133127 - Investigate integrating HAL into gnome-pilot
Summary: Investigate integrating HAL into gnome-pilot
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-pilot
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact:
Depends On: 77881 133341
TreeView+ depends on / blocked
Reported: 2004-09-21 19:45 UTC by Dave Malcolm
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

Fixed In Version: gnome-pilot-2.0.15-10.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-10-22 11:49:19 UTC
Type: ---

Attachments (Terms of Use)

Description Dave Malcolm 2004-09-21 19:45:44 UTC
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

Comment 1 Dave Malcolm 2004-11-04 18:32:24 UTC
Adding to FC4 Target tracker

Comment 2 Dave Malcolm 2004-11-08 21:36:36 UTC
I've posted some initial code to the HAL and gnome-pilot mailing lists

Comment 6 Matt Davey 2006-04-25 13:01:29 UTC
gnome-pilot CVS now has some HAL support, which should appear in gnome-pilot-2.0.14.

Comment 9 Jens Knutson 2006-10-30 18:49:41 UTC
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?

Comment 10 Matthew Barnes 2007-04-03 00:55:15 UTC
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.

Comment 11 Matthias Clasen 2007-04-03 15:07:08 UTC
Too bad. Taking this off FC7Target then. We really need to find a better
strategy for this bug.

Comment 14 Matt Davey 2007-04-10 10:05:45 UTC
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).

Comment 15 Matthew Barnes 2007-04-10 11:22:47 UTC
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?

Comment 16 Matt Davey 2007-04-10 13:17:36 UTC
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:
udev rule.

Comment 17 David Zeuthen 2007-04-10 21:47:57 UTC
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.

Comment 18 Matthias Clasen 2007-04-10 23:42:44 UTC
Matt, thanks for following up. Obviously, we were not quite uptodate as to where
things currently stand. 

Comment 19 Matthew Barnes 2007-10-21 12:54:42 UTC
Matt, just curious if there's any progress to report here for Fedora 8.

Comment 20 Matt Davey 2007-10-22 08:39:42 UTC
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.

Comment 21 Matthew Barnes 2007-10-22 11:49:19 UTC
Cool, thanks for the update.  I'll close this, then, as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.