HAL: camera

[David Zeuthen]

On Wed, 2004-01-14 at 22:35, Matthew Mastracci wrote:
> Sean Middleditch wrote:
> 
> > is it considered 'bad form' to have multiple capabilities (in different
> > namespaces/categories) for the same thing?  hierarchy kinda sucks when
> > its overly rigid as it can't express things as they really are, but it
> > does avoid a lot of clutter and guesswork.  ("ok, which of the 10 image
> > capabilities should I put for this device?")
> 

I don't think this would be bad form. If I insert a CD in my drive then
HAL creates a device object and it will have capabilities 'block' and
'volume'. 

The desktop policy engine (such as gnome-volume-manager) then checks the
volume, discovers that the filesystem is DCF-compliant (e.g. got a DCIM
tree) and adds the capability 'camera'.

> I'm not an expert on this particular bit of the design, but I believe 
> that the core HAL system is designed to expose capabilities at a kernel 
> level only.  It's up to other user-space devices to expose additional, 
> richer capabilities themselves.
> 

Not necessarily; HAL could merge capabilities through a device
information files. 

However, as it's not practical nor smart to have a zillion .fdi files we
might want to put dedicated code / tables into the HAL daemon to detect
capabilities. One such example is cameras. 
Now, libgphoto support several hundreds cameras and I believe they have
a table of them in their library. We shouldn't duplicate this table
(neither in hal source code or .fdi files), so either

 1. hald invokes gphoto when detecting a USB device
 2. hald links with libgphoto to check USB devices

Neither of these options are really appealing; any ideas? 

In HAL 0.1 the device information files was python scripts; maybe one
should be able to have callout in our XML-based .fdi files? Then we
would have a single .fdi that would invoke gphoto.

> For instance, gphoto might take:
> camera
> camera.image
> camera.movie
> multimedia.video
> etc...
> 
> and create a gphoto.image capability with some sort of reference for 
> gphoto aware apps.  It would be up to gphoto to determine how to get a 
> still image from a camera, scanner or v4l device.  When you want to use 
> a gphoto device, you'd pass it the HAL device path, it would look up the 
> object and automatically figure out how to provide you with a still image.
> 

This would require buy in from all such libraries - for instance I'm not
sure that the gphoto folks would be happy to provide support for a HAL
device of capability 'volume', 'camera' (usb-storage based cameras) as
they could argue that this would be silly since it's already in the
file-system.

Maybe what we should do instead, is to have a freedesktop.org library
for every capability (e.g. libhal_camera, libhal_musicplayer)? 

This would solve the issue in the above paragraph and allow to mark
scanners as having capability 'camera' and then use libsane instead of
libgphoto. Network transparency issues (as discussed in another thread)
could also be dealt with there.

Thoughts, ideas?

Cheers,
David