[sane-devel] Sane and HAL
Johannes Meixner
jsmeix at suse.de
Fri Jan 5 10:18:42 CET 2007
Hello,
On Jan 4 19:32 abel deuring wrote (shortened):
> <device>
> <match key="usb.vendor_id" int="0x043d">
> <match key="usb.product_id" int="0x007c">
> <append key="info.capabilities"
> type="strlist">scanner</append>
> <append key="scanner.vendor" type="strlist">Lexmark</append>
> <append key="scanner.model" type="strlist">X1140</append>
> <append key="scanner.api" type="strlist">sane</append>
> <append key="scanner.sane.backend"
> type="strlist">lexmark</append>
> <append key="scanner.sane.supportstatus"
> type="strlist">untested</append>
> <merge key="scanner.sane.is_supported"
> type="bool">true</merge>
> </match>
> </match>
> </device>
I see some problems:
1) vendor and model strings:
According to epkowa.desc the Epson Perfection 600 is a
rebadged UMAX Astra 1200S so that the "lshal" entries would be
scanner.model = {'Perfection 600', 'Astra 1200S'}
scanner.vendor = {'Epson', 'UMAX'}
But now it is not clear for an application which gets this values
which model belongs to which vendor - or can the application really
rely on the ordering?
For example alphabetical sorting (which is often done somehow
automatically when lists of strings are processed) results:
scanner.model = {'Astra 1200S', 'Perfection 600'}
scanner.vendor = {'Epson', 'UMAX'}
As usb.vendor_id and usb.product_id are used for unique device
discovey and unique device identification, there is no need
to keep the human readable strings for vendor and model seperated
and one single scanner.model entry which contains also the vendor
name in its values should be sufficient so that it would be
scanner.model = {'Epson Perfection 600', 'UMAX Astra 1200S'}
2) support status:
The support status depends on the individual backend (the status
in the desc files is below the backend in the hierarchy).
Therefore it should be scanner.sane.<backend-name>.supportstatus
where <backend-name> is one of the values in scanner.sane.backend.
And then there seems to be no need for a strlist because one
might think that for each backend there can be only one support
status for one usb.vendor_id and usb.product_id but unfortunately
this is not true, see the example below for the
Epson Perfection 1250 (Photo).
I think scanner.sane.is_supported is redundant because
one could simply use the special backend name "unsupported"
for the scanners in unsupported.desc. I think there is no need
for a special processing for unsupported.desc, simply process
it as any other desc file and leave it for the applications
what they like to do with the information.
3) comments:
Additionally it might be useful to have also the comment
from the desc files in the fdi file as
scanner.sane.<backend-name>.comment
so that the user can be informed.
Example:
Now a "nice" example which shows that it becomes all messed up
if it is not unique (e.g. multiple model names and multiple
backends).
It is for the Epson Perfection 1250 (Photo) / GT-7200U
which I made from the epkowa.desc and plustek.desc files, see
http://www.sane-project.org/cgi-bin/driver.pl?v=04b8&p=010f
Note the "nice" unexpected side effects because of different
spellings of vendor and model name in epkowa.desc and plustek.desc
and the cofusing two support status for the plustek backend
and the trebled same support status from epkowa.desc and the
multiple comments (obviously the comments provide useful
information but it looks so much cofusing and duplicated).
<device>
<match key="usb.vendor_id" int="0x04b8">
<match key="usb.product_id" int="0x010f">
<append key="info.capabilities"
type="strlist">scanner</append>
<append key="scanner.model"
type="strlist">Epson Perfection 1250</append>
<append key="scanner.model"
type="strlist">Epson Perfection 1250 Photo</append>
<append key="scanner.model"
type="strlist">EPSON Perfection 1250</append>
<append key="scanner.model"
type="strlist">EPSON Perfection 1250 PHOTO</append>
<append key="scanner.model"
type="strlist">EPSON GT-7200U</append>
<append key="scanner.api" type="strlist">sane</append>
<append key="scanner.sane.backend"
type="strlist">plustek</append>
<append key="scanner.sane.plustek.supportstatus"
type="strlist">complete</append>
<append key="scanner.sane.plustek.supportstatus"
type="strlist">good</append>
<append key="scanner.sane.plustek.comment"
type="strlist">TPA scans not perfect</append>
<append key="scanner.sane.backend"
type="strlist">epkowa</append>
<append key="scanner.sane.epkowa.supportstatus"
type="strlist">good</append>
<append key="scanner.sane.epkowa.supportstatus"
type="strlist">good</append>
<append key="scanner.sane.epkowa.supportstatus"
type="strlist">good</append>
<append key="scanner.sane.epkowa.comment"
type="strlist">requires DFSG non-free
iscan-plugin-gt-7200
also supported by the
plustek backend</append>
<append key="scanner.sane.epkowa.comment"
type="strlist">overseas version of the GT-7200U
requires DFSG non-free
iscan-plugin-gt-7200
also supported by the
plustek backend</append>
<append key="scanner.sane.epkowa.comment"
type="strlist">Perfection 1250
with TPU option bundled
requires DFSG non-free
iscan-plugin-gt-7200
also supported by the
plustek backend</append>
</match>
</match>
</device>
Ovbiously it seems to be better to keep exactly the hierarchy
of the desc files because it is all totally clear at
http://www.sane-project.org/cgi-bin/driver.pl?v=04b8&p=010f
In particular the comment should be below the model name in the
hierarchy and the example shows that also the support status
should be below the model name in the hierarchy so that it
becomes clear that the Perfection 1250 Photo is only good
(but not complete) supported by the plustek backend because
"TPA scans not perfect".
But I don't know how to do it in HAL because I cannot have
a model name string like "Epson Perfection 1250 Photo"
as (part of) a key in HAL (like I did it to get the support
status below the backend in the hierarchy).
> > "HAL support in SANE" versus "SANE support in HAL":
...
> I think it is better to keep the file in the Sane package.
I fully agree.
For example the HAL people could pick up the fdi file
from the SANE project if they like to provide it in their
HAL package.
Or we could build our HAL RPM with our SANE RPM installed
in the build system so that our HAL RPM could contain the
fdi file from our SANE RPM (if we like to have it this way).
The crucial point is that the fdi file is created, maintained
and located at the SANE project because only here is the real
source of the information for the fdi file.
> > Think about a fdi file from Epson Avasys for their scanners
> > which is included in their driver and the same scanners
> > are also already listed in the HAL or SANE fdi file(s).
>
> I hope that my proposal for the "scanner namespace" can deal with
> this case
Yes, in particular the scanner.api is crucial here because
this strlist contains the sub-keys for the sub-namespaces
for whatever other kind of drivers so that an application
can query HAL for the entries in the particular sub-namespace
(at least simply via "lshal | grep scanner.<api-value>").
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix at suse.de
90409 Nuernberg, Germany WWW: http://www.suse.de/
More information about the sane-devel
mailing list