[sane-devel] SANE OS X 10.3 Install Problems
It's been a while since I've been able to concentrate on SANE, apologies for my absence. I added the OSX_ONLY_10_2_API and OSX_ONLY_10_1_API defines as I knew the old API was going to go, but didn't have time to test on Panther at the time. Could someone add a test to the config script ? The new API works fine in Panther (at least if it is compiled on Jaguar), and I've got a bit of extra code to handle the sense codes to submit to CVS, unless someone has added that already. I'll try and take a look at this over the weekend. Cheers Guy On 20/11/03 10:02 am, Phil Barrett p...@cambridgeanimation.com wrote: Well, I can't help because I don't have any MacOS X experience but maybe one of the OS X hackers can. So I quote everything and send it to sane-devel. Please reply to sane-devel, not to me personally. -DV_MAJOR=1 -DV_MINOR=0 -D_REENTRANT -g -O2 -W -Wall sanei_scsi.c sanei_scsi.c:210:35: IOKit/cdb/IOSCSILib.h: No such file or directory ... Simple enough: this header is an old API, which is not included in OS X 10.3 (Panther). The code for the new API is in sanei_scsi.c already, so the solution is just to define OSX_ONLY_10_2_API somewhere. It seems this wasn't defined before, so I suspect the code using the new API has to be considered untested and potentially buggy. (Note that it fails to compile using gcc 2.95 without some reorganisation of variable and function declarations in the new API code.) Phil
[sane-devel] Epson driver - rounding problems
Hi, Surprised by some of the values I was getting in a custom frontend I was writing, I tried a test using scanimage to be sure it wasn't me. Low and behold... % scanimage -x 25.4 -y 25.4 --resolution 100 i.e a 1 inch by 1 inch image, at 100 dots per inch should produce an image of 100 by 100 pixels. However it produces an image of 96 by 99 pixels. Looking at epson.c, sane_get_parameters() line 3767/8 I see there is a rounding problem when determining the number of pixels :- s-params.pixels_per_line = SANE_UNFIX( s-val[ OPT_BR_X].w - s-val[ OPT_TL_X].w) / 25.4 * ndpi; s-params.lines = SANE_UNFIX( s-val[ OPT_BR_Y].w - s-val[ OPT_TL_Y].w) / 25.4 * ndpi; Should be :- s-params.pixels_per_line = SANE_UNFIX( s-val[ OPT_BR_X].w - s-val[ OPT_TL_X].w) / 25.4 * ndpi + 0.5; s-params.lines = SANE_UNFIX( s-val[ OPT_BR_Y].w - s-val[ OPT_TL_Y].w) / 25.4 * ndpi + 0.5; With the original test, this results in an image of 96 by 100 pixels. The reason for 96 pixels is on line 3833 where the pixels per line are rounded down to the nearest multiple of eight (i.e 96, 104, 112...) s-params.pixels_per_line = s-params.pixels_per_line ~7; Why does it do this ? Is it a limitation of the driver, or of Epson scanners, and if so, why does it not round up, and throw away the unwanted pixels ? In a similar vein, is there not also a rounding problem in the definition of SANE_FIX() #define SANE_FIX(v)((SANE_Word) ((v) * (1 SANE_FIXED_SCALE_SHIFT))) Should this not be ? #define SANE_FIX(v)((SANE_Word) (0.5 + (v) * (1 SANE_FIXED_SCALE_SHIFT))) Cheers, Guy
[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
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
