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"