Fri, 02 Apr 2010
Driverless Scanner
Historically, there has always been a problem with drivers for scanners in Linux. We have had SANE, but it was quite common when shopping for a new scanner to discover that all supported scanners are out of sale. With HP and their HPLIP the situation is definitely better. Few days ago I have discovered even better solution which requires no drivers and no scanning software installed.
I have a multifunction printer/scanner from HP. It works with HPLIP (of course), but it is still not very straightforward to figure out what should I run and under which user (I have a multiseat desktop). The device supports scanning to (and printing from) a memory card - it has slots for all types of memory cards except USB-based ones. So it is possible to scan to a memory card, and then use it to transfer the data to the computer without any driver for a scanner, I thought. And now comes the clever part:
The trick is that when the card is inserted to the printer, it becomes accessible in the host computer as a mass storage device as well. Only when actually saving scanned images to the card, it is virtually unplugged from the host computer, and made accessible again afterwards. So there is no need to move the card around, just keep it in the slot of the printer. Look ma, no drivers!
So good work, HP! The next minor improvement could be to have a small flash inside the device itself, and use the scanner as a mass storage device exclusively.
2 replies for this story:
Milan Zamazal wrote:
This is fine simplification but it works only in in very simple cases when all you need is to use just the predefined scanning process. So it's OK for a multifunction device but not for a more sophisticated scanner. The proper solution is not hiding the drivers inside the device but to make writing regular drivers as easy as possible.
Yenya wrote: Problems with scanners
The main problem with scanners is that there are not widespread, and from the narrow user base even narower subset would _ever_ need a non-standard process settings. So such drivers would be untested, buggy, and painful to use. You would essentially end up with 99 % of users using scan-to-the-flash feature (because the UI and workflow is better than xsane anyway). The UI can definitely be improved by e.g. being able to save the raw data from the sensor as TIFF. But with scanners being in production for half a year before being replaced, writing new drivers is simply not feasible. That said, I would definitely support a free-specs hardware. But in case of many users of many scanners, we are better off with scan-to-the-flash than with free or non-free drivers.