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
