[sane-devel] Solaris 8 and SANE
Henning Meier-Geinitz
henning at meier-geinitz.de
Tue Jun 11 21:06:37 BST 2002
Hi,
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.
Bye,
Henning
More information about the sane-devel
mailing list