The SANE Scanner Interface
Now that you have seen how to use some of the programs that come with the SANE distribution, it is time to tell you what else is included. At the time of this writing, the package includes drivers for the following devices:
Connectix QuickCam (color and monochrome)
Some Epson SCSI scanners
Hewlett-Packard ScanJet SCSI scanners
Microtek SCSI scanners
Mustek SCSI flatbed scanners (both one-pass and three-pass scanners are supported)
PINT devices: PINT is a Unix-kernel interface for NetBSD, OpenBSD and SunOS. SANE's PINT driver provides access to any scanner for which there is PINT support
Most UMAX SCSI scanners
Support for many other scanners and cameras is planned and some of them should be ready by the time you read this article. For the latest information, please visit the web page listed in the Resources.
Available applications are the command-line scanimage, the graphical xscanimage (either stand-alone or as a GIMP extension) and xcam, a graphical user interface suitable for cameras which produce a continuous stream of images (such as the Connectix QuickCam).
In addition, there are SANE API bindings for Python and Java API and a network daemon called saned that provides network-transparent access to remote devices. Assuming you have the appropriate permissions, this makes it possible to control a camera running in the U.S. from a machine running in Europe—all courtesy of SANE and the Internet.
When building a SANE application, it must be linked against the shared library called libsane.so. In reality, libsane.so is just a symlink to one of the SANE drivers. Since every SANE driver exports the exact same interface, you can change the libsane.so symlink at any time and effectively change which driver the application is using. While this is useful in the sense that it allows upgrading to a different driver without having to relink all the applications, it would not be very convenient if you had to change a symlink whenever you wished to switch the scanning device. For this reason, SANE supports two pseudo-drivers called dll and net. They are pseudo-drivers because rather than talking to physical devices, they talk to other SANE drivers, as illustrated in Figure 5.
For machine A, the libsane.so symlink points to the dll pseudo-driver (called libsane-dll.so). That pseudo-driver uses dynamically linked libraries (dll) to access other SANE drivers. In the example, dll is configured to use the pnm, mustek and net drivers. The net driver is again a pseudo-driver; it provides access to remote scanners by connecting to the SANE daemon (saned) running on machine B. Machine B in turn uses dll again to provide access to a variety of other drivers. As you might imagine, the exact configuration is entirely up to the system administrator(s) of machines A and B. It is fairly typical to have libsane.so be a symlink to the dll pseudo-driver, but there is no reason it couldn't point to the net pseudo-driver or just the mustek driver. Of course, in the latter case the implication would be that applications could access the mustek driver only—but that's perfectly reasonable for certain environments.
This approach is very flexible, but it raises an interesting question: how do we name devices in such an environment? The answer is that every real driver has its own device name space. For example, the Mustek and HP drivers use the path for the Unix special device that controls the device, such as /dev/scanner. With pseudo-drivers, things get a bit more interesting. Since dll must guarantee that each device name is unique, it simply prefixes the name of each subordinate device with the name of the subordinate driver, separated by a colon. Thus, on machine A, the mustek scanner would be called mustek:/dev/scanner. The net pseudo-driver does something similar: it prefixes the remote device name with the remote host name (again using a colon as a separator). For example, HP scanner 1 on machine B would appear on machine A under the name net:B.domain.com:hp:/dev/scanner1. While this doesn't make for the world's prettiest names, the information contained in the names is actually quite useful. In essence, much like a Unix path name, the device names convey the path through the SANE hierarchy that leads to a particular device. For example, if you know that machine B is down, it's pretty obvious that net:B.domain.com:hp:/dev/scanner1 will be down as well. If someone feels strongly about these names, it is possible for an application to let a user or system administrator define aliases that are more concise. For example, an application could let a user rename the above device to “HP Scanner 1”, which may be easier for beginners.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Many Paths to a Solution
- Nativ Disc
- Synopsys' Coverity
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- Glass Padding
- Identity: Our Last Stand
- CodeLathe FileCloud Google Chrome Extension
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide