[sane-devel] Sane and HAL

[abel deuring]

Hi Johannes,

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

right, now things are starting to become intersting ;)

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

I was too not 100% sure, if we can rely on the order of entries in
string lists, so that we can "correlate" the entries from two lists
by their indexes. Need to ask that on the HAL mailing list. But
let's assume for now that we can rely on the order.

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

yes, this would indeed be nonsense ;)

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

One string for vendor/model is indeed fine, if it is used only for
user information, and if a user-visible list of such entries is
"short enough", i.e., if this string is not used to build a list
like that for the printer configuration with hundreds of entries.
For the latter, the typical grouping of the models by vendor is
convenient. Admittedly, I don't see that such lists are a "real
option" for HAL, but I am not yet convinced that we should use the
same string for vendor/model. Additionally, we can get some
information about a device with a HAL callout, including the vendor
and model name as detected by Sane backends (struct SANE_Device),
and separate fields for for these values in the "HAL database" makes
it easier to find the matching data.

> 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 intended supportstatus to be a string list of the same length as
the backend list, and the entries of both lists should correlate the
same way as the vendor and model lists. But anyway, a
sub-sub-namespace for each backend works too, and makes things
perhaps easier. But I think that these namespaces should get a
prefix, like scanner.sane.backend_<backend-name>.supportstatus .
Using only the backend names is a bit "uncontrollable", I think.

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

Right, is_supported is redundant. The key scanner.api should get the
value "sane" if and only if at least one backend supports the
device. If this is case, the sub-namespace scanner.sane is
populated, otherwise it is left empty.

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

OK; let's add the comments, at least those for individual devices.

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

Indeed a good choice ;)

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

Avoiding name inconsistencies as in your example will occur again
and again, I'm sure. But they can be fixed by "unifying" the
spelling quite easily.

> 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

Yes, if possible, the hierarchy should be, where possible. The
problem is that the _backends_ are at the top of hierachy of the
*desc files, while HAL has individual _devices_ at the top of its
hierachy (more precisely, at the top of that branch of the hierarchy
we want to provide inforamtion for).

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

Well, I think that your example gives the most "fine-grained"
information we can get with fdi files. A HAL callout which opens the
device with all possible backends can be used to remove "irrelevant"
entries, if the backend can identify the device somewhat "more
precisely".

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

The HAL folks seem too to prefer to not include a scanner fdi file,
but to leave it to Sane.

As I understand it, the GPhoto project does it the same way: They
maintain their fdi file, or have a generator script for the file.

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

Right: It is up to you and your colleagues from the other Linux
distributions to decide what is the best place for the scanner fdi
file. What we will need is a common name and a common location for
the file, so that people, who want to install Sane from the source
files because the "offical" versions for the various distributions
do not yet support their scanner, do net get mad by installing a
duplicate of the file.

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

So that's fixed :)

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

Right. My idea is (1) to provide enough data so that an application
can search for a scanner in the HAL data, check if it supported by
the Sane API, figure out how to access it (device file name etc) and
finally call sane_open() with this data, (2) to provide data for the
OS for things like permission management and (3) provide useful end
user information.

Abel

Abel