[sane-devel] Solaris 8 and SANE

Henning Meier-Geinitz henning@meier-geinitz.de
Tue, 11 Jun 2002 22:06:37 +0200


On Tue, Jun 11, 2002 at 01:43:27PM -0400, Kip Iles wrote:
> >I think I will add a comment about missing/unknown parport, USB and other 
> >support.
> Thanks! That would certainly help others researching this problem.
> I suppose the 1st sentence in README.solaris should state that "ONLY" SCSI 
> devices are supported by SANE under Solaris rather than implying the fact 
> by describing a user mode generic SCSI driver requirement. Thats what sent 
> me off on a tagent looking for SCSI<->USB converters, etc. I think it would 
> be ludicrous to bottleneck SCSI down to USB (1.1) anyway.

Ok, it's changed in CVS.  There is also a "no" entry in the USB column
of the list of supported platforms for Solaris on the website.

> >I think you can't use it to connect USB scanners. The only way to use a 
> >SCSI generic driver would be some sort of converter in the kernel and a 
> >USB scanner that is accessed over SCSI commands. I don't know if souch a 
> >converter (SCSI-over-USB) exists for Solaris.
> Even if it did. it would be too cost prohibitive for my use. Im after the 
> most cost affective solution for a massive implementation for a customer. 
> SCSI doubles the cost of the scanner.

My idea wasn't a hardware USB-to-SCSI converter but a real USB scanner
and a kernel driver that can speak USB to the scanner but listens to
SCSI commands from userspace. If I remeber correctly, there is a
similar driver fo some HP scanners (?) on Linux.

> >The interface used by most backends is sanei/sanei_usb.c.  It's build 
> >around the assumption that there is one single device file that represents 
> >an USB scanner. So you need a kernel driver fo this job. Currently I know 
> >that this works with Linux, OpenBSD and FreeBSD. The epson backend also 
> >uses this approach but accesses the device file directly (without the 
> >sanei_usb layer).
> Yeah - I have no actual /dev/usb(anything) on this server because the USB 
> root hub is actually a SunRay (ultra-thin) client. I do have a Quatech 
> USB>Serial device that is "Sun Ready" and it is recognized by the SunRay 
> server software so it does get a pseudo device node created for it. If I 
> can get specifics on what that device sends out to get special attention I 
> could replicate that into a backend that would do the same thing for the 
> Epson 1650U. Right now I have to assume that the SunRay Server software 
> thinks the epson is just another HID device and does not generate any 
> device nodes for it.

Any method to access USB devices would probably be sufficient. The
Linux scanner driver doesn't do much but provide a device file that
can be used to write to (USB bulk write) and read from (USB bulk
read). So all the intelligence is in the backends.

> >The sm3600 backend uses libusb. However, I don't think Solaris is 
> >supported by libusb, is it? As far as I know, only Linux and the BSDs 
> >currently work.
> There are some internal rumblings at Sun about libusb but I dont think its 
> there, yet. UGEN is a different story. I believe that has recently been 
> ported over from BSD. I have not found much about UGEN backends in the 
> sane-devel archives. Basically I am trying to implement this with more 
> integration/configuration, and less device driver/Sane backend development. 
> If I have to make mods to SANE source or create a new backend - that 
> becomes another piece that must be integrated, documented, distributed, and 
> supported. The customer wants SANE because its easier for them to write 
> their frontend.

The epson backend is a special case because of its direct access.
Otherwise I would have proposed to add the Solaris special code to
sanei/sanei_usb.c. Which we should do anyway. Unfortunately I have
only remote access to a Solaris system and that's rather old and
doesn't have USB.