Red Hat Bugzilla – Bug 431498
pilot-link using libusb doesn't work with Palm Zire 22
Last modified: 2008-02-25 19:27:15 EST
pilot-link doesn't work using libusb with a Palm Zire 22, though patches have
been posted to the pilot-link mailing lists:
As far as I can see, this patch has not been included upstream yet. Fedora may
want to carry this patch in the meanwhile?
F8 currently has pilot-link-0.12.2-17.fc8 in updates. libusb is preferred over
the visor module to avoid udev compatibility problems (bug #280251, bug #158809).
I can't find the patch associated with the January pilot-link-devel posting (by
David Desrosiers, which appears to refer to an earlier post by Brenda J. Butler
that I can't find, either). Do you have a better URL for it?
googling for the email title, it seems the thread started on pilot-link-general:
I would probably try Tom Billet's November 2007 patch first:
I don't have a Zire 22 myself, so please let us know how you get on. The
pilot-link-* lists are fairly low traffic - I see there are a few threads on
Zire 22 problems that it may be worth reading if you get stuck?
Created attachment 294069 [details]
Tom Billet's patch to allow Z22 and libusb to get along
This is the actual patch from the pilot-link-devel list referred to above.
Created attachment 294070 [details]
This is a patch to the specfile to apply the wonderful patch
(Bugzilla ate my comments and report on the success garnered by using Billet's
patch mentioned above, from memory)
Hallelujah, that works to make pilot-link talk to my Z22 via usb:, provided I
revert to hwdata-0.207-2.fc8.
Since the patch merely updates a lookup table of USB vendor:device pairs and
sets a flag, which is a lot like what PolicyKit is using hwdata for in order to
(try to) set the permissions of the created device properly, I must
whole-heartedly urge everyone to read and ponder comment #87 in bug #280251,
which now seems to revolve around the hwdata device identification / PolicyKit /
Of course, since Palm chose to ambiguate device identification using 0830:0061,
this should get tested with all the other Palm devices that share this id.
Great! From the source, it looks to me like idstr is a value retrieved from the
Palm during it's initial communication with the pilot-link libraries, rather
than something derived from hwdata - do you agree?
I'm sure reports of this patch working would be appreciated on pilot-link-devel
- hopefully it'll get included upstream.
(In reply to comment #6)
> I'm sure reports of this patch working would be appreciated on pilot-link-devel
> - hopefully it'll get included upstream.
Scratch that, looks the patch made it into pilot-link HEAD in November:
(bah, I was previously looking at svn.pilot-link.org, which seems to be a dead-end)
WRT comment #6, while I agree that idstr is not derived from hwdata, I drew
precisely the opposite conclusion from the source. idstr is extracted from the
lookup table in usb.c. This is a structure, known_devices, of type
pi_usb_dev_, that is populated within the function USB_poll() in libusb.c,
which, in turn, appears to march through a linked list of usb busses and, for
each, traverses a linked list of devices, extracting the vendor:product USB ids.
In other words, I believe that idstr is derived by pilot-link from the
vendor:product that it reads from the Palm, in parallel to what PolicyKit is
doing, i.e. doing a lookup in hwdata based on a key that it reads from the
Palm's vendor:product USB ids.
I forgot to mention earlier: as you say, we need users of other 0830:0061
devices to try this. According to idstr, that means Zire 31 and Zire 72 users. I
don't own either, I'm afraid. The F8 starting point was that pilot-link (libusb)
didn't really work at all, so that may make it more acceptable to carry the
patch and see what happens?
In reply to comment #8:
Yeah, sorry, I was unclear - I saw known_devices. I think we've identified the
same thing (that hal/polkit and pilot-link both do independent vid/pid lookups),
but come to different conclusions.
The experience of bug #280251 has taught me to only ever rely on vid/pid
lookups, not the resultant strings from hwdata/pilot-link vid/pid lookups (and
the hwdata maintainer has confirmed this approach). And as I said over in that
bug, pilot-link and hal/polkit need to do different things once they've
identified the device anyway. What clicked today is that the hal/polkit vid/pid
matching should happen in those rules themselves, not indirectly via hwdata.
Given this, I don't see much scope for sharing the vid/pid lookup, unless the
pilot-link quirk flags (USB_INIT_SONY_CLIE etc.) were also exposed through hal -
and I don't think pilot-link would want a dependency on hal/udev anyway. I
suppose pilot-link could expose a function/utility to return the vid/pids it
recognises and this could be used to generate the .fdi file.
http://www.linux-usb.org/usb.ids isn't any good for either task, unfortunately.
I can see why hal was written ;)
pilot-link-0.12.2-18.fc8 has been submitted as an update for Fedora 8
pilot-link-0.12.2-18.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update pilot-link'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1611
pilot-link-0.12.2-18.fc8 doesn't work for me, alas. Comparing the SRPM I put
together (which builds a working pilot-link) and the SRPM for
pilot-link-0.12.2-18.fc8 (which doesn't), I'm forced to conclude that the
problem is in pilot-link-0.12.2-18.fc8's 19-pam-acl-management.fdi which is the
same as in pilot-link-0.12.2-17.fc8, which simply doesn't work.
In order to get pilot link working, I absolutely had to use Kevin's .fdi file
from comment #100, bug # 28051 (
https://bugzilla.redhat.com/attachment.cgi?id=294520 ). I haven't tried Kevin's
second fdi file, from comment #101, bug # 28051 (
https://bugzilla.redhat.com/attachment.cgi?id=294521 ), because I, at least,
don't need it get a working setup.
Oops, typo! s/28051/280251/g in comment #12 (The ( URLs ) are correct though.
Joe: yes, the pilot-link-0.12.2-18.fc8 referenced here _only_ contains the
specific patch to correct pilot-link USB initialisation with Zire 22s.
The generic PolicyKit/ACL issues still remain from bug #280251; that is where
they will be resolved in time - we are currently waiting for review and feedback
from the HAL maintainer, and there may be further revisions before a solution is
pilot-link-0.12.2-18.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.