HAL and scanners

[Martin Owens]

Hey all,

A very interesting project to try and get sane integrated nicely with
hal, but I think it can provide a good bond to help users.

>
> Many USB vendor/product IDs identify a chipset which is used by by
> different vendors in sometimes quite different models. Figuring out
> the "best" entry would require in many cases at least a callout that
> uses something like "scanimage -L". Gerhard Jäger lists for example
> three different scanners that share the USB vendor/product IDs
> 0x07b3/0x0017, and there are many more similar cases.
>

The best way to do this is to mark these kinds of scanners in the fdi
file as 'undecided' and return an error from the scan method that the
model is not defined enough (or some such) at least then we wouldn't
have the wrong firmware being uploaded to the wrong device.

To choose which model it should be from a list is quite easy to do, if
it should be a list of all possible models defined in the fdi which an
application or cli tool could make use of this would be ideal (would
need to be user readable).

The thing we have here is that the one thing we know differentiates
each of the scanners is the oem badging. we need to ask the user and
we mustn't be ashamed of doing so where required; a standard way of
presenting this choice to programs using hal would be nice as above.

To store the value against the scanner we've been talking about using
either the usb serial number for usb devices; or the port it is
plugged in for usb/scsi/para not sure how well this kind of thing can
be included in the fdi/hal infrastructure.

>
> >>5. Does it make sense to list unsupported scanners in the fdi file?
> >
> > I don't think so.
>
> Sorry, my question was a bit terse. People ask more or less regulary
> on the Sane mailing list questions like "I bought the scanner XYZ
> made by company ABC. I tried to connect it to my Linux box but I
> can't use it. What should I do?" Unfortunately, the answer is quite
> often "sorry, this scanner is not supported by Sane. Somebody
> already tried to ask the vendor for developer documentation, but got
> no response." It could make sense to give a user an idea what can be
> done or not done, if s/he plugs in an unsupported scanner. But this
> is a policy question (and anyway at present pure theory -- I don't
> know about any "end-user visible" hotplugging functions for scanners
> under Gnome or KDE, comparable to opening a file browser when a
> memory stick is plugged into a USB port), so I'll just add an option
> like "--include-unsupported" to the fdi generator script.
>

I don't think you guys shouldn't worry too much about unsupported
devices, it's not in your scope of your project to deal with them; as
I've talked about before dohickey.sourceforge.net on the other hand
does have unsupported hardware information in it's scope and providing
as much information as is possible to the users. this should help when
users have hardware that isn't supported because dohickey has online
information repositories which are accessed as information is
required; allowing new hardware to be noted as unsupported before hal
can make a dev release.

> >
> > You mean to do probing? DavidZ suggested a way to do this for serial
> > ports on the list a few months ago, although nothing has been done yet.
> > See the thread here:
> > http://lists.freedesktop.org/archives/hal/2006-September/006086.html
> >

It's a good start, a formalised way of accessing and probing passive
ports is important. the first thing to do is to have the ports marked
as passive, have a few methods which try to detect certain things, be
they scanners or ups's

Best Regards, Martin Owens