Subject: Re: Retiring 'ss*' and PINT in favour of SANE
To: Brett Lymn <email@example.com>
From: David Brownlee <firstname.lastname@example.org>
Date: 01/14/2000 21:21:15
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
> 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.