On Thu, 13 Jan 2000, Brett Lymn wrote:

> According to Berndt Josef Wulf:
>
> >>> Same here... Wouldn't it be possible to integrate scanner support for
> >>> devices other than the twain/hp products into the ss* driver? It
> >>> doesn't seem to make sense and isn't very intuitive using a uk*
> >>> (unknown) device for a known product.
> >>

	Other people are maintaining support for scsi scanners in SANE.
	Adding to the kernel not only add unnecessary kernel code, but
	it then means we have to maintain it - lack of maintenance brought
	up this whole debate.

	If someone is going to volunteer to extend and maintain the
	ss* driver, then we should consider it, otherwise we need to
	find a different solution.

> >>   It probably would suffice if ss* supported the generic SCSI commands
> >> that uk* does ...
> >
> >Thanks, this is actually what I've tried to convey....
> >
> 
> Actually, I had a look at this when I was bored once in my hotel room
> (too many long blacks to sleep ;-) and was part of the way through
> rewriting ss.c (well, in honesty it was a cut & paste of uk.c ;-)
> when I noticed that all you really need to do is remove/disable the
> minor number check in the ioctl function.  If we ifdef these lines
> out (at the bottom of the function ssioctl in ss.c):
> 
>                 if (SSMODE(dev) != MODE_CONTROL)
>                         return (ENOTTY);
> 
> then SANE should work with the ss device.  You can actually test this
> by making a scsi scanner device node with a minor number of 3 like
> this:
> 
> mknod /dev/scanner c 19 3
> 
	Shouldn't this be minor 1 (MODE_NONREWIND) - currently the code
	permits ioctl() on minor 3 (MODE_CONTROL) only, but prohibits I/O.
	
> and see if SANE works properly with /dev/scanner.  If it does we have
> a few choices:
> 
> 1)  Remove the code from the ss.c ioctl - I cannot see that it will
>     break anything to be quite honest.
>
> 2) Make a standard scanner device node with a name that SANE looks for
>    by default that has a minor number of 3.
> 
> 3) Put the information in the FAQ - this would be good to do anyway
>    but I don't think it is the best solution.
> 
> I would think option 1 would be most preferable.  Unfortunately, I
> have lost access to the scanner I was playing with so I cannot test
> these suggestions.

	Can anyone else who has had a problem with the ss* driver try
	this? Otherwise I think we should comment it out until someone
	does - that breaks fewer people than the current situation.

		David/absolute