On 21/8/03 12:28 pm, "Henning Meier-Geinitz" <henn...@meier-geinitz.de> wrote:
> > Maybe you or someone else could also have a look at README.darwin and > make sure it's uptodate. > Will do. > >> It still supports the previous implementation which uses the deprecated SCSI >> Family IOKit API, so all being well it should not break anything that has >> previously worked. > > >> I have added some #ifdefs which may allow it to be compiled when either the >> old or new i/f are not available, but this has not been tested. To use just >> the old API, compile with OSX_ONLY_10_1_API defined, and to use just the new >> API, compile with OSX_ONLY_10_2_API defined. By default neither are defined, >> and both APIs are used. > > What happens if someone only has 10.1? Does it break compilation or > just not use the new interface? If it breaks, some autoimatic test in > configure would be nice. > By default, both APIs are compiled. If only one of the APIs are available, one of the flags OSX_ONLY_10_1_API or OSX_ONLY_10_2_API could be defined, which should remove all evidence of the other API during compilation. I don't actually know if this is needed or not, or even if it works, but it just seemed like a good idea while I was coding. I need to be able to find a way to compile under 10.1 to check it out. Apples new Xcode tools seem to have the ability to cross compile for previous systems. I'll take a look this weekend and see what happens if I configure it to compile for 10.1 If that doesn't work so well, I can try and dig out some 10.1 CDs and try and find an empty disk to install on, but that might take a little time to get around to doing. Alternatively, does anyone else on this list have 10.1 + Dev Tools on a machine that they can try to build sane 1.0.12 plus the patch for me ? > >> As you can see from above, the device name is made up, and I use the text >> 'iokitscsi@<' followed by the SCSIUserClient GUID from the IO Registry. That >> is the unique ID for the client, and allows me to refind the device very >> quickly. The only problem is that the number will change after reboot, or if >> the device is unplugged, and replugged into the firewire port. > > Is the device detected correctly by just using the "scsi ..." > directives in the backend files? In this case the actual name doesn't > leally matter. That's similar to USB devices supported by libusb. The > name changes after every replug. > Yes, the backend calls sanei_scsi_find_devices, which looks up all matching SCSI and FireWire devices in the IO registry, so it is completely transparent to the rest of sane. >> sane-find-scanner does not work, as it hard codes device names for each >> platform. Just use scanimage -L > > Someone could add support to sane-find-scanner to use the MacOS API > :-) For libusb, there are already special functions. > Sure, as long as it is OK to call sanei_scsi_find_devices from sane-find-scanner. I had looked at the code of sane-find-scanner, and was surprised to see that instead of calling sanei_scsi_find_devices like the frontend/backends, it seems to have hardcoded device names in /dev that it tries one after the other for specific platforms. I assumed this was to provide an alternative method for looking for devices than scanimage -L. As there is no equivalent on OS X, I assumed there was no need to add anything to that command, but it should be straightforward to add a call to sanei_scsi_find_devices to ensure completeness if you would like me to. My assumption is that I would call it with no vendor/device lun etc to match (so it will find all scanner types on all busses) and an attach routine that just lists the device name, and vendor/model name from the registry, without calling any of the backends. Does that sound correct/useful ? I promise to stop using // by the way ! The last few days I've been working on a sane to TWAIN Data Source, and have made some progress, but there is still quite some way to go yet. Cheers Guy