HAL and scanners

[abel deuring]

Hi,

Martin Owens wrote:
> 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.

The question is, what one expects from HAL: Only a hint that the USB
ID is known, or a list of possible devices. But I'll add an option
to reduce the device information from "USB ID 0x1234/0x5678 could be
model A, model B..." (several <device> definitions) to "this is
(probably) a supported scanner", i.e., just one <device>...</device>
definition.

Another point: Not all backends that support scanners with this kind
of "ambiguous IDs" need to upload firmware files. (a really user
friendly firmware upload solution requires, BTW, probably a somewhat
larger effort: For some scanners, you can download the file from the
vendor's website; for other scanners, you must unpack a .CAB file
from a CD; and some Sane man pages even recommend to install the
Windows driver and look for the firmware file in windows/system32 or
wherever. And Sane has at present no consistent way to define the
firmware in the backend's configuration.) But this is probably a bit
off-topic for the HAL mailing list.

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

As already stated elsewhere, I don't know much about (cheaper) USB
scanners and their malices. But some backends might be able to
detect the actually available scanner model by reading some
registers; other backends will of course need user intervention for
a configuration. Again, I'd like to postpone this discussion to a
later time. Without input/feedback from the maintainers of the
affected Sane backends we'll most talk about hot air.

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

We are talking mostly about configuring cheap USB scanners: I don't
believe that many of them have serial numbers. (Even "better"
scanners like some Fujitsu models can be a bit funny in this
respect: The fi5120 scanners for example _have_ a serial number --
but this number is AFAIK not available as a standard USB property.)
Using the USB port would not work for me ;) I connect a USB device
quite often to a different port. But again: Let's leave this
discussion for a later time.

SCSI scanners should not raise any configuration problem that
requires user intervention (except the well-known things like broken
cables, bent connector pins, wrong/missing bus termination, double
use of SCSI IDs and whatever other mistakes users can make with the
SCSI bus) or need anything that must be stored in a config file,
once the device is properly detected by the kernel driver and once
device file permissions are adjusted.

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

well, people ask quite regulary about unsupported scanners on the
Sane mailing list and look on the project's website, so the list of
unsupported scanners is used in order to build a web page that lists
these devices ;) Having more than one information source of
(un)supported devices is fine -- let's simply keep both your list
and the one provided by the Sane project ;)

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

The parallel port might be a bit more complicated: At least some
printers are able to tell the host machine their name -- but I have
no idea if some parallel port scanners can do that too.

Abel