Julien BLACHE <jb at jblache.org> writes:
> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>
>> Hmm, I think we could use a wild card here, like so
>>
>> ATTRS{type}=="3", ATTRS{vendor}=="EPSON", ATTRS{model}="SCANNER*"
>>
>> and be done with. WDYT?
>
> As it is right now, we have a scanner <-> IDs mapping in the desc files,
> and it can be used both ways.
With both ways meaning mapping a scanner model to an ID and an ID to a
scanner model, right? To some extent that is not quite true. Just have
a look at the 04b8/085e USB vendor/product ID combination which maps to
seven entries in the latest epkowa.desc.
ME OFFICE 900WD Series
PX-503A
Stylus Office BX525WD
Stylus NX625
Stylus SX525WD
Stylus TX560WD Series
WorkForce 625
Seeing that two of two sport a "Series", there's probably even more.
I just analysed the USB device in latest epkowa.desc a bit and there are
only 24 USB product IDs that map to a unique entry (two of which sport a
"Series" moniker). A grand total of 101 USB product IDs map to two of
more entries.
If, however, you interpret the mapping as a scanner H/W interface to ID
(and back) mapping, then of course your argument holds. Or am I reading
too much in your "<->" and incorrectly assumed a 1:1 mapping from that?
> If we add this wildcard, we'll never complete this mapping, which I
> think has some value in itself.
The value of the mapping depends on the use case, IMHO.
The original poster had trouble getting his device recognised by the OS
as a scanner. For that, I don't see little to no value in getting a
complete mapping. For this purpose, you'll always be playing catch up.
Even if you're using the latest git snapshot, you will be behind the
times. Let alone when using your distribution's packaged sane-backends.
For this scenario, getting the OS to recognise a device as a scanner, I
think wildcards are useful.
In fact, a SCSI device with ATTRS{type} == "6" already is a kind of
wildcard and no-one has any qualms about that being in libsane.rules.
# Here's me wishing USB had a scanner class ... :-(
Now that the OS has detected a scanner, we roll into the next use case:
finding a backend/driver that makes the thing work. You're out of luck
here at the moment and will have to do the legwork yourself. For this
case, an (on-line and programmatically accessible) ID to backend/driver
mapping is of great value. With such a mapping, the OS can check if the
required backend/driver is already installed (and if not offer to do so,
perhaps?). Please keep in mind that one may need a third-party SANE
backend or even something like Kodak's TWAIN driver for Linux. That is,
sane-backends is not the be-all-and-end-all of scanner support.
# Of course, the IDs in such a mapping can also be used to check whether
# some device might be a scanner.
Then there is the hapless user looking for a scanner that works on their
OS. For this, a scanner model (name as printed on the box!) to support
status mapping (per backend/driver) is essential. Then there might be
people that want to know whether a backend/driver is Free Software (or
crippled by conditions that won't let you help yourself or a neighbour)
or folks looking for a support contact, or ...
Oops, getting a bit off-tangent here so I'll leave it at this. For now
at least because I'd really like to see something like automatic scanner
"driver" download become reality, just like it did for printers with the
release of Ubuntu 11.04. The more scanners Just Work out-of-the-box the
better!
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962 Help support software freedom
http://www.fsf.org/jf?referrer=1962
