PDA support in HAL - making synchronisation "just work"

[David Zeuthen]

Hi Dave,

On Mon, 2004-11-08 at 16:12 -0500, David Malcolm wrote:
> (Crossposted to HAL and gnome-pilot mailing lists)
> 
> I've been looking at cleaning up parts of gnome-pilot, and feel that
> some of it really belongs in HAL.
> 
> gnome-pilot has a daemon, gpilotd, which monitors for pilot devices, and
> has a conduit system that can be invoked when a device connects.
> 
> Currently gnome-pilot's device monitoring requires the user to configure
> the system, typing in names of devices, and potentially set up obscure
> files on their computer (e.g. udev configuration).
> 
> If built on Linux with WITH_USB_VISOR, the gpilotd wakes up every 2
> seconds and scans /proc/bus/usb/devices, looking for PDA devices based
> on USB product/vendor ID pairs.
> 
> So I'm thinking that some of this really belongs in HAL instead; it
> would be great if HAL could handle the low-level device detection work,
> and provide desktop-level tools with a list of PDAs.  When the user
> wants to synchronise their data, HAL should make some call out to an
> appropriate tool, perhaps in a similar way to how gnome-volume-manager
> can mount devices automagically (perhaps even using gnome-volume-
> manager, for the case of the GNOME desktop).
> 

I think this looks pretty good and I'll be happy to include it in hal.

Basically, the issue of device nodes and ownership can be dealt with a
hal callout - just check if the device got the 'pda' capability and then
change the permissions as appropriate. Note that this is distribution
specific though - in Fedora I'd like to change the permission to that of
the console user; I'm not sure how to do this on Debian, Gentoo or SUSE?

Regarding taking the appropriate action in the desktop environment, this
can be dealt with in either a separate program (just listen on D-BUS
signals from hal) or through a more high-level policy daemon (I know
that John Palmieri has some thoughts about that).

> gnome-pilot has an XML file (gnome-pilot/gpilotd/devices.xml) which
> contains information on known USB PDA devices, in its own format.
> 
> Attached is an XSL file which transforms that file into a HAL .fdi file;
> I've also attached a copy of the resulting file (after going through
> xmllint --format).  I've been putting this file
> into /usr/share/hal/fdi/50user for now.
>
> The FDI file basically takes the list of specific USB vendor/product ID
> pairs, and adds info.capability="pda" for every known pair; it also adds
> a boolean "pda.use_net" based on the value in the original gnome-pilot
> file.
> 

We should include this in 20freedesktop (since it would be included with
the hal tarball).

> Finally, I've attached a patch to hal-device-manager which adds an icon
> for PDAs.  I'm currently using an icon from gnome-pilot as hal-pda.png -
> however that module is under a GPL license; I've emailed the artist,
> hoping for permission to relicense.
> 
> The obligatory screenshot of hal-device-manager using all of the above
> is here:
> http://people.redhat.com/dmalcolm/Screenshot-PDA-HAL.png
>
> Thoughts?
> 

I think this is cool. 

I have only one concern which is that the way it works with your patch
is that we assign the capability 'pda' to the device object that is the
parent of the two device objects with the serial device nodes. 

Now, I'm not sure I understand why there are two serial device nodes for
the PDA in the first place? Are both of them used? I'm assuming that
only one is used. We need a way to figure out which one to use (might
need some extra properties one the usb-serial hal device objects to
determine this).

Perhaps the best way to do it, would be to have a property
'pda.serial_port_device' with the UDI of the device with the capability
'serial_port' (much like we have block.storage_device and
storage.physical_device). 

Then the use case for a desktop application would be something like this

 1. Find device X of capability 'pda'
 2. Find device Y of by taking the UDI stored in the string property
    'pda.serial_port_device' on device X
 3. Lookup serial_port.device_node on device Y
 4. Use that device (e.g. /dev/ttyUSB0 or whatever)

To do this, we would have to add code to the usb_serial_bus_device.c to
catch if the parent has capability 'pda' and if so, store it in the
property pda.serial_port_device on the parent. I think that is fair
enough. 

Doing it this way would also make it work if we put in polling of
ordinary legacy serial ports on those x86 boxes - does anyone know if
it's feasible to poll for a PDA on such ports? (for this, actually, the
device object with the 'pda' capability would be a child of the serial
port - but that won't matter much since we have defined the
pda.serial_port_device property :-)). 

Finally, we may support devices with a kernel driver (not sure such
devices exist but we may want to keep the door open) by defining the
property pda.access_method and saying that if pda.access_method has
value 'serial_port' it implies that it is a serial port device and
pda.access_method has the value 'foobar' that it uses the foobar driver
etc.

We will of course need to document all this in the hal spec so it is
easy to use :-). I think it may suffice to document the pda.* properties
(which would include pda.serial_port_device).

Cheers,
David



_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal