improving digital camera detection

[David Zeuthen]

On Mon, 2005-01-17 at 23:45 +0100, Pozsar Balazs wrote:
> I am sure that we should merge this property, because if an usb device 
> has a ptp interface it _is_ a camera, and this property is not about 
> gphoto support, but being a camera.
> 

Sure, we can merge this with camera.access_method=ptp, OK? We'll just
arrange this such that this gets checked before gphoto2 .fdi files.

So that fdi file should be

 fdi/20freedesktop/00-camera-check-ptp.fdi
 (was ptp.fdi)

> > > massstorage.fdi:
> > >   This is a trickier one. If the USB device's interface indicates it is 
> > >   a Mass Storage device, then we set the camera.access_method key to 
> > >   "storage", BUT we do not set the info.capabilities or info.category.
> > >   This way, if the device is marked as a camera somewhere else, it will 
> > >   have the proper camera.access_method key/value pair.
> > > 
> > 
> > This actually looks pretty clever; how about testing that the 
> > property camera.access_method exists before setting it to
> > storage?
> 
> I think we should not do that. Firstly, because camera.access_method may 
> not be set elsewhere, secondly it would make it too dependant on the 
> ordering. (this property would have to be set _earlier_ than this 
> check.)
> 

We do have ordering of .fdi files; see the spec. I'm against of just
merging camera.access_method=photo on each and every USB Mass Storage
Interface so we'll need this; do you disagree?

This would be

  fdi/20freedesktop/99-camera-check-usb-storage.fdi
  (was massstorage.fdi)

> > > libgphoto2.fdi
> > >   This is a bit ugly.
> > >   Basically, it is a collection of the usb id's of various digital 
> > >   cameras known by libghoto-2.1.5. (It is though a much better start, 
> > >   than the single sony_dsc.fdi...)
> > >   I have created the file using a little script, which I have also 
> > >   encapsulated in the xml as a comment for later reference, so it won't 
> > >   get lost.
> > > 
> > 
> > I think we should have a file like this but it should be supplied
> > libgphoto2, yes? As others have pointed out, it's pretty 
> > straightforward to patch gphoto2 to give us such a file as
> > it's pretty much the same as /etc/hotplug/usb.usermap or
> > whatever it's called on a distribution. How about doing a patch
> > for gphoto2 to generate this?
> > 
> > Reason is that I don't think it's wise to have this information
> > in both HAL and gphoto2.
> 
> Well...
> The .fdi file containing the ids _must be_ in the hal package _not_ the 
> gphoto package. I want my cameras have the camera property in hal, and 
> this must not depend on gphoto being installed on my system.
> 
> I agree, that syncronization would be easier if gphoto had an .fdi file 
> to merge.
> 
> Moreover, think about that there might be cameras for which gphoto does 
> not and will not have an id because it does not support it. HAL _should 
> have_ ids for these too -- again, this property is about being a camera, 
> and not about gphoto support.

We can do this; we just merge camera.access_method=unknown; right now
this is probably not useful though.

About your libgphoto2.fdi file, this would just be 50-camera-
libgphoto2.fdi.
Whether distros want to ship 50-camera-libgphoto2.fdi is their issue; I
don't
mind (that much) carrying it around in the tarball provided someone
updates
it once in a while :-)

Want me to commit it with these changes?

David


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