improving digital camera detection

[Pozsar Balazs]

On Mon, Jan 17, 2005 at 08:40:33PM -0500, David Zeuthen wrote:
> 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)

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.


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

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

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 :)


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



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