Re: gnome-pilot-2.0.14pre4 testing and fixes

[Matt Davey <mcdavey mrao cam ac uk>]

On Mon, 2006-05-29 at 12:34 -0700, Nathan Owens wrote:
> This weekend, I finally got a chance to try gnome-pilot 2.0.14pre4. I found some problems with it,
> which were easy to fix. See the attached patch.
> 
> The problems found:
> 1) usb.vendor_id and usb.product_id should have been usb_device.vendor_id and
> usb_device.product_id, when getting values from HAL

You're right, the combination of info.bus='usb_device' and
'usb.vendor_id=blah' shouldn't possibly work.  I definitely had HAL
syncs, but maybe that was before I added the match on info.bus??  No
matter.

By the way, I posted a question to the hal mailing list, because my fc5
system (hal-0.5.7-3.fc5.1) wasn't picking up the palm pda capability.
It would be great if we could use the hal detected ttyUSB device if it
exists - do you know whether the classdev.c/cvs change is what's
required here?

My aim is to release something that is robust and has the least
stringent requirements for hal versions.  You might have seen that the
first HAL patch matched on the pda capability, but just didn't work for
me out of the box, so I reverted to using HAL in conjunction with the
devices.xml file.  Not quite as whizzy, but it seems more reliable.

> 2) The string used to match devices in devices.xml wasn't being formulated properly - the format
> string needed to be "%04x" instead of "%4x" for the leading 0's.

Oops.  Thanks.  It would be better to change to using integer rather
than string matching, but it seemed simpler to leave the legacy
usbfs/sysfs code as is.

> 3) When using HAL with either pilot-link 0.11.8 or 0.12pre4, pi_bind would fail. The reason for
> this is most likely due to HAL notifying gpilotd that a device has been attached before udev has a
> chance to actually create the device files. I've put in a while() loop to wait until the device
> files have been created. It will timeout after 1 second (i.e. udev has 1 second to create the
> device file - my tests showed it usually took a few milliseconds at most).

Great catch.  These udev timing issues have been real annoyance over the
past year or more.  I've found some similar issues recently.  In the
visor_devices_timeout() function I added a sleep after sync, to prevent
trying to sync again before the udev device has disappeared.  Shouldn't
affect the HAL case because it only tries to sync after a device connect
signal.

> I also had to get a file from HAL's CVS repository: classdev.c. Without it, HAL 0.5.7 would
> recognize the device, but fail to probe it (you can't probe a USB device using a serial probe
> method). While I think gpilotd would still have worked (I found the HAL change before the gpilotd
> changes), I think it's wise to use a CVS version of HAL if possible.
> 
> With these changes to gpilotd, I have had no troubles whatsoever in synchronizing. The only
> conduit I'm currently able to use is the backup one, as the other conduits have not been converted
> to the new API. Matt, will you be converting these?

I haven't looked into it, to be honest.  I know jpr committed
contributed patches for 0.12 conversion to gnome-pilot-conduits back in
November last year so it shouldn't be in bad shape.  Fedora was shipping
an 0.12 based gnome-pilot (don't mention the war...) so at least had
compilation working.  I haven't tested how complete that all is, so any
work here would be good.

> Also, the Evolution conduits will need to be converted. I believe there's a patch for the EAddress
> conduit floating around out there right now. I plan on doing those conduits myself, since I use
> Evolution a lot and I haven't seen any talk about them on the evo-hackers list lately.

Again, the fedora effort should have seen some work here, even if
incomplete.

> Let me know what you think of the patch. I'll let the list know if I find anything else.

The patch is great.  I'll commit it asap.

By the way, I'm about to post a HIG patch, in case you feel like
reviewing that, too.

Thanks,

Matt

Matt Davey		What has four legs and one arm?	
mcdavey mrao cam ac uk 	     A happy Rottweiler.