[sane-devel] OS X Firewire support

[Guy Brooker]

On 21/8/03 12:28 pm, "Henning Meier-Geinitz" <henning at 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