improving digital camera detection

[David Zeuthen]

On Tue, 2005-01-18 at 11:31 +0100, Pozsar Balazs wrote: 
> > 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)
> 
> If you mean:
>     <merge key="info.category" type="string">camera</merge>
>     <merge key="info.capabilities" type="string">camera</merge>
>     <merge key="camera.access_method" type="string">ptp</merge>
> 
> then it is okay for me.
> 

Yeah, btw, it should probably be

 fdi/10generic/ptp-camera-check.fdi

instead, so it comes before any user supplied files.

> > > > > 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
> 
> (probably you mean camera.access_method=storage)
> 

Right.

> > Interface so we'll need this; do you disagree?
> > 
> > This would be
> > 
> >   fdi/20freedesktop/99-camera-check-usb-storage.fdi
> >   (was massstorage.fdi)
> 
> I agree that it would be a bit ugly to merge this prop for every mass 
> storage device. But:
>  - I think it would be desireable, because it only means that
>    "IF it is a camera, then its access method is storage."

Then it needs info.capabilities and info.category updated as well, yeah?

>  - If I have a camera with an usb id not listed somewhere in 
>    20freedesktop/*.fdi, I have to create an .fdi file under 
>    20freedesktop because of the ordering.

Right, yeah, it should probably be

fdi/90systempolicy/camera-check-usb-storage.fdi

instead.

> Just as a side note, I would recommend using only seq numbers between 10 
> and 90, you can never why you will need 99 later :)
> 

Right; I was kind of forgetting, but it's a bit smarter to use
the already predefined directories for this.

> 
> > We can do this; we just merge camera.access_method=unknown; right now
> > this is probably not useful though.
> 
> I think we should not merge such a prop, because it has no information.
> If the prop (camera.access_method) does not exists, it has the same 
> meaning and it is much cleaner imho.
> 
> 
> > About your libgphoto2.fdi file, this would just be 50-camera-
> > libgphoto2.fdi.
> 
> That is ok for me.
> 
> 
> > 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 :-)
> 
> I do think it should be part of the hal package, and updated when 
> needed.
> 

Sure this can just lead to extra maintenance overhead but I suppose
people can adjust this as appropriate. So to conclude:

 1. fdi/10generic/camera-check-ptp.fdi
 2. fdi/20freedesktop/camera-check-libgphoto2.fdi
 3. fdi/20freedesktop/camera-check-usb-storage.fdi
 4. fdi/90systempolicy/camera-check-fixup-usb-storage.fdi

These are processed in order; we still need number 3. but that can
be generated from Hubs page

 http://www.teaser.fr/~hfiguiere/linux/digicam.html

and can be taken from libgphoto2 in the future. Can you rework your
files to fit this?

Thanks,
David

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