[sane-devel] OS X Firewire support
Hi, On Thu, Aug 21, 2003 at 05:44:43PM +0200, Guy Brooker wrote: 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 think it is ok to do that. 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. I'm not sure if this is really the reason. My guess is that in the early SANE releases you had to hardcode the device file (e.g. /dev/sg2) or use the /dev/scanner link. Therefore you needed a way to find the scanner's device file. Probably sanei_scsi_find_devices is just newer (and not implemented on every platform). 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. It's not high-priority but I think it may help to locate problems when a scanner is found by the operating system but not by a backend. And it would stop questions from Mac OS X users like Why is my scanner not found by sane-find-scanner? 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 ? Yes. Look at sanei_scsi.c itsself, sanei_scsi_find_devices() is called there in a similar way to find out the buffer size. Bye, Henning
[sane-devel] OS X Firewire support
Hi, On Sun, Aug 17, 2003 at 02:47:33PM +0200, Guy Brooker wrote: OK, a zip archive for the patch to 1.0.12 is available at http://homepage.mac.com/guy_brooker/.cv/guy_brooker/Public/Sane/sane-backend s-1.0.12-osx.zip-link.zip Thanks for your work. I've applied the patch to SANE CVS. I've changed all the // comments to /* */ because otherwise SANE doesn't compile with warnings enabled on my system. I can't test on MacOS X, so some reports about success/failure woruld be nice (in case I broke something). Maybe you or someone else could also have a look at README.darwin and make sure it's uptodate. An unofficial snapshot of the current CVS is here: http://www.meier-geinitz.de/sane/snapshots/ 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. % scanimage -L device `epson:iokitscsi@0450201222af34a59175' is a Epson GT-7000 flatbed scanner As does xsane (which I installed using fink) The only problem I have is that both these tools need dll.conf and epson.conf in the current working directory, they don't find the version in the standard location for some reason. I'll look into that later, but I don't think it has anything to do with my changes. Maybe something with the path delimiter is wrong? 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. 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. Bye, Henning
[sane-devel] OS X Firewire support
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
[sane-devel] OS X Firewire support
On 12/8/03 5:06 pm, Martijn van Oosterhout klep...@svana.org wrote: On Tue, Aug 12, 2003 at 03:46:45PM +0200, Guy Brooker wrote: Hi, I've almost completed testing of a patch to sane_scsi.c which supports the IOKit SCSI Architecture Model API. Very cool stuff! 1. Use diff to work out the differences between the base version and your changes 2. Or just post the code and how to make it work. OK, a zip archive for the patch to 1.0.12 is available at http://homepage.mac.com/guy_brooker/.cv/guy_brooker/Public/Sane/sane-backend s-1.0.12-osx.zip-link.zip It only modifies one file, sane-backends-1.0.12/sanei/sanei_scsi.c 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. The modifications should allow Firewire scanners, and SCSI scanners plugged into a firewire-SCSI bridge (such as Orange Micro's) to work with sane under Jaguar and future OS's. I have only been able to test it with my EPSON GT-7000 on my iMac. Please could other interested parties give it a go and let me know if you have any success ? scanimage -L works fine : % scanimage -L device `epson:iokitscsi@0450201222af34a59175' is a Epson GT-7000 flatbed scanner As does xsane (which I installed using fink) The only problem I have is that both these tools need dll.conf and epson.conf in the current working directory, they don't find the version in the standard location for some reason. I'll look into that later, but I don't think it has anything to do with my changes. 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. sane-find-scanner does not work, as it hard codes device names for each platform. Just use scanimage -L I am now thinking about implementing a TWAIN Data Source, but it seems a huge job The windows ones don't seem to be much of a starting point, but Apple provides some basic sample code that might get me started. If anyone else has started on that, could you drop me a line ? Cheers, Guy
[sane-devel] OS X Firewire support
This really is cool stuff... It works even with real IEEE1394 EPSON scanners - that is if you have the current CVS version of the backend. I tried it with an EPSON GT-3 scanner connected via IEEE-1394. The scanner gets correctly reported by scanimage -L, and I did a number of successful scans. Great job, Karl Heinz On Sunday, August 17, 2003, at 08:47 AM, Guy Brooker wrote: On 12/8/03 5:06 pm, Martijn van Oosterhout klep...@svana.org wrote: On Tue, Aug 12, 2003 at 03:46:45PM +0200, Guy Brooker wrote: Hi, I've almost completed testing of a patch to sane_scsi.c which supports the IOKit SCSI Architecture Model API. Very cool stuff! 1. Use diff to work out the differences between the base version and your changes 2. Or just post the code and how to make it work. OK, a zip archive for the patch to 1.0.12 is available at http://homepage.mac.com/guy_brooker/.cv/guy_brooker/Public/Sane/sane- backend s-1.0.12-osx.zip-link.zip It only modifies one file, sane-backends-1.0.12/sanei/sanei_scsi.c 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. The modifications should allow Firewire scanners, and SCSI scanners plugged into a firewire-SCSI bridge (such as Orange Micro's) to work with sane under Jaguar and future OS's. I have only been able to test it with my EPSON GT-7000 on my iMac. Please could other interested parties give it a go and let me know if you have any success ? scanimage -L works fine : % scanimage -L device `epson:iokitscsi@0450201222af34a59175' is a Epson GT-7000 flatbed scanner As does xsane (which I installed using fink) The only problem I have is that both these tools need dll.conf and epson.conf in the current working directory, they don't find the version in the standard location for some reason. I'll look into that later, but I don't think it has anything to do with my changes. 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. sane-find-scanner does not work, as it hard codes device names for each platform. Just use scanimage -L I am now thinking about implementing a TWAIN Data Source, but it seems a huge job The windows ones don't seem to be much of a starting point, but Apple provides some basic sample code that might get me started. If anyone else has started on that, could you drop me a line ? Cheers, Guy ___ Sane-devel mailing list sane-de...@www.mostang.com http://www.mostang.com/mailman/listinfo/sane-devel
[sane-devel] OS X Firewire support
Hi, On Tue, Aug 12, 2003 at 05:43:26PM +0200, Guy Brooker wrote: I was wondering though if there are some restrictions on function call naming ? I've added quite a few private functions to sane_scsi.c that are only compiled under OS X, but have a more OS X like naming convention than those found in the rest of sane. Is that a problem ? I don't think so. While doc/backend-writing.txt /that's probably the file you searched for) wants the GNU coding style, I don't think it's that important for low-level os-dependend stuff. Bye, Henning
[sane-devel] OS X Firewire support
--gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2003 at 03:46:45PM +0200, Guy Brooker wrote: =20 Hi, =20 I've almost completed testing of a patch to sane_scsi.c which supports the IOKit SCSI Architecture Model API. Very cool stuff! I need to complete some testing, and to tidy up the code a little beofre I post it, but before I do, can someone point me to some information on wha= t I need to do to prepare and submit a patch to SANE ? I am sure I came across some documentation on the subject last week, but I can't find it via the standard web site anymore. (I'm sure it is staring me in the face!) I don't know if there is a specific document but you have a choice. 1. Use diff to work out the differences between the base version and your c= hanges 2. Or just post the code and how to make it work. If it's verified by a developer with CVS access, they can just commit it for you. But posting allows other people to test, which is always a good thing. Remember, make sure the code is readable and clear. Document any sections not obvious. Some poor schmoe might need to debug it later :) --=20 Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ All that is needed for the forces of evil to triumph is for enough good men to do nothing. - Edmond Burke The penalty good people pay for not being interested in politics is to be governed by people worse than themselves. - Plato --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/OQJ2Y5Twig3Ge+YRAg7+AKDRHfAoko8kFYZdHR5ofzPMv3it8wCgshVD 6c6SOkL1z6dgIax/6gbHijg= =MhSr -END PGP SIGNATURE- --gKMricLos+KVdGMg--
[sane-devel] OS X Firewire support
Hi, I've almost completed testing of a patch to sane_scsi.c which supports the IOKit SCSI Architecture Model API. The original OS X SCSI code in SANE 1.0.12 used the old IOKit SCSI Family API, which is deprecated in OS X 10.2 and may not be supported in future versions of OS X. The new API works in 10.2 and later. I followed Apples guidelines to support both APIs, but I don't have a machine running 10.1 to test it on to be sure the previous code (largely untouched) still works. The advantage of the new API is that it not only supports SCSI devices on standard SCSI buses, but also FireWire devices that use SBP-2 (an encapsulation of SCSI). To non-programmers that means most FireWire scanners, and also SCSI scanners plugged in via a SCSI-FireWire bridge (such as Orange Micros device) should be supported This has allowed me to successfully scan from my old EPSON GT-7000 SCSI scanner on my iMac (which has no SCSI controller) using SANE ! I need to complete some testing, and to tidy up the code a little beofre I post it, but before I do, can someone point me to some information on what I need to do to prepare and submit a patch to SANE ? I am sure I came across some documentation on the subject last week, but I can't find it via the standard web site anymore. (I'm sure it is staring me in the face!) Cheers, Guy
[sane-devel] OS X Firewire support
On 12/8/03 5:06 pm, Martijn van Oosterhout klep...@svana.org wrote: I don't know if there is a specific document but you have a choice. 1. Use diff to work out the differences between the base version and your changes 2. Or just post the code and how to make it work. If it's verified by a developer with CVS access, they can just commit it for you. But posting allows other people to test, which is always a good thing. Remember, make sure the code is readable and clear. Document any sections not obvious. Some poor schmoe might need to debug it later :) Thanks, I'll do a diff once I've been able to complete testing. I was wondering though if there are some restrictions on function call naming ? I've added quite a few private functions to sane_scsi.c that are only compiled under OS X, but have a more OS X like naming convention than those found in the rest of sane. Is that a problem ? Cheers, Guy
