[sane-devel] OS X Firewire support
Thu, 21 Aug 2003 17:44:43 +0200
On 21/8/03 12:28 pm, "Henning Meier-Geinitz" <firstname.lastname@example.org>
> Maybe you or someone else could also have a look at README.darwin and
> make sure it's uptodate.
>> 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
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.