HAL and scanners

David Zeuthen david at fubar.dk
Mon Jan 8 09:15:19 PST 2007


On Thu, 2007-01-04 at 20:07 +0100, abel deuring wrote:
> OK. Eventually, the question, how many hardware details should be
> available to HAL and where this information is located, is anyway
> decided by the package maintainers of the various Linux
> distributions. Keeping the fdi file (or even better, only the
> generator script and some callouts) in Sane minimzes bureaucracy.
> 
> Johannes Meixner (from Novell/Suse) came up on the Sane mailing list
> with the question, how conficts can be avoided, if we have more than
> one fdi file. For example, Epson distributes its own Sane backend.
> Any recommendations for fdi file names and locations in
> /usr/share/hal/fdi ?

Make sure the fdi files go in 

 /usr/share/hal/fdi/information/20thirdparty/

and have your project name included in the file name, e.g.
10-sane-scanners.fdi. 

Then propose that SANE backends distributed not as part of the SANE
package uses a higher number, e.g. 90-epson-sane-scanners.fdi and then,
because fdi files are processed in order, 90 will be processed before
10. Would that work?

> From a different dicussion I understand that Étienne intends to keep
> the gnomescan API "open enough" to be able to integrate other
> low-level scanner APIs. So it might make sense to optionally add
> gnomescan. But this is a question we can leave to the Gnome developers.

Agreed.

> OK. There were some discussions, if a key like
> "scanner.is_supported" or "scanner.sane.sane.is_supported" makes
> sense; meanwhile I think that this is redundant: The namespace
> "scanner.sane" should only be populated, if a device is supported.
> Similary, scanner.api should only get the entry "sane", if a backend
> is available. So I'll drop the value "unsupported"
> scanner.sane.supportstatus.

Sounds OK to me.

> > That's just adding an entry to info.callouts.add that runs a program
> > where you can modify the properties you've already merged.
> 
> OK; if some "equivalent" of "scanimage -L" is run, we'll get the
> "real" vendor/model information. In this case, only
> 
> BTW: If such a callout exists, couldn't the vendor/model information
> for supported scanners be removed from the fdi file, or are there
> use cases for HAL, where this data could be used, when a specific
> device is not present? The fdi file has even today (without most
> SCSI scanners) a size of 300 kB...

So that would work too. Just make sure the call out only runs for the
USB ID's that you support; e.g. we don't want to run the SANE USB
scanner callout for _every_ USB device attached. That would make HAL
startup even slower.

Thanks for hacking on this!

     David




More information about the hal mailing list