[sane-devel] HAL and scanners.

m. allan noah kitno455 at gmail.com
Tue Mar 18 17:32:36 UTC 2008


On Tue, Mar 18, 2008 at 12:48 PM, abel deuring <adeuring at gmx.net> wrote:
> Hi all,
>
>
>  On 18.03.2008 17:15, Étienne Bersac wrote:
>  > Hi,
>  >
>  > I answer both allan and abel in this mail.
>  >
>  >> we can also add a function like sane_get_device_information to the
>  >> Sane API that would return data like USB bus and devices numbers […]
>  >
>  >> A HAL callout can then call sane_get_devices, call
>  >> sane_get_device_information for each Sane device and can this way
>  >> decide, if a Sane device "matches" the "current" HAL device.
>  >
>  > So basically, we have have two solutions :
>  >
>  >      1. a HAL callout + sane_get_device_informations()
>  >      2. a SANE meta backend
>  >      3. extends the meaning of sane_open()
>  >
>  > I actually prefer the first since it imply less modification in SANE.
>  >
>  > Something good would be to avoid reloading all backends since HAL know
>  > which backends support the device. Something like
>  > sane_backend_get_devices would be very cool.
>
>  That is one step too far -- we should get an agreement about the basic
>  stuff first ;) But the HAL callout could also mess with dll.conf and
>  enable those backends that "fit" to a newly detected scanner. Though
>  this might also be a bit dangerous: The callout should not touch any
>  backends for devices that are for example accessible via ethernet.
>
>
>  >
>  > Which solution is the right ? Other solution are welcome ;) Please
>  > comment.
>
>  Without much thinking, I think one could also write a meta-backend using
>  a function like sane_get_device_information. But I'd prefer to leave the
>  legwork to a HAL callout.
>
>  Also, I think that it would not be too much work to implement the
>  function sane_get_device_informations (but remember: I'm talking about
>  work that I cannot promise to do myself...). If we allow backends to
>  return "sorry, can't provide any device data" -- and that is necessary
>  for example for the test backend --, we can in a first step add a dummy
>  function to all backends that simply returns SANE_STATUS_UNSUPPORTED.
>  Most newer scanners have a USB interface and most if not all "related"
>  Sane backends use the sanei_usb library to access the devices, hence it
>  would probably be sufficient to implement a function like
>  sanei_usb_device_info in sanei_usb, which can be called by the backends
>  in sane_get_device_informations. A similar common function can be
>  implemented in sanei_scsi.c.
>
>  I believe that the main challenge is to define the data to be returned
>  by sane_get_device_informations in such a way that it is useful at least
>  for USB and SCSI scanners, and hopefully also for IEEE1394 and parport
>  scanners -- on different platforms, with/without libusb usage etc.
>  [sorry, I'm going back to work without making any specific proposals...]
>

this does sound like it would be a useful function, but i think it is
replicating quite a bit of what hal does inside of sanei or the
backends. theoretically, hal already knows most of the info we are
talking about sending. extending sane_open just a bit to always
support 'libusb:xxx:yyy' or '/dev/sgX' is not an API change, so could
be implemented much sooner, and really only requires changes to the
backends that dont already use those names, which is few.

allan
-- 
"The truth is an offense, but not a sin"


More information about the sane-devel mailing list