HAL: camera

[Sean Middleditch]

On Thu, 2004-01-15 at 13:36, David Zeuthen wrote:
> On Wed, 2004-01-14 at 22:35, Matthew Mastracci wrote:

> > 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.

Well, if gphoto switches to use HAL, then it would make sense to move
the information out of gphoto into HAL - perhaps.  Or just use callout.

I was actually thinking out loud in another email reply that it would be
great to have callout capabilities for HAL events, because a lot of
things really just don't need Yet Another Daemon sitting in the
background just to respond to events.

For example, if HAL does the media insertion/removal detection, then
instead of a daedmon that just sits and listens for HAL events, HAL
could callout to a command-line interface to do these things (reducing
background memory usage - there would be more time spent starting the
app to do the work, but does that matter in this case?)

> 
> > 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?

Do we really need to make the capabilities implementation-specific?  The
question apps are going to be asking are "is this a camera that supports
still images?"  That's really what capabilities are for, from my
understanding.

Things like "which gphoto driver if any supports this device" aren't
capabilities, they're additional attributes.  Devices that have the
'camera.image' capability and a non-empty 'gphoto.driver' attribute
would be used by apps that use gphoto.  In fact, the app may very well
want to list in its UI *all* devices with 'camera.image', and then just
grey-out (or otherwise mark) devices without usable 'gphoto.driver'
attributes so that users know the devices isn't usable or supported in
the app, and not just that the app can't find it.  But that's UI design,
which I guess is off topic.  ~,^

> 
> Cheers,
> David

-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.