[sane-devel] Question on SCSI-scanners

[Dieter Jurzitza]

Dear listmembers,
dear Abel,
dear Allan,
thanks for the pointers. First of all, a "grep processor" within the 
desc-files results in nothing. I personally do not see a way how to extract 
this information from the desc-files, but maybe (hopefully!) I overlooked 
something.

For better explanation: I started working on the fdi-file to include support 
for scsi scanners. Everything that announces itself as "scanner" is readily 
supported. Howerver, I have a SCSI-Scanner from HP here that announces itself 
as "processor", so as you readily confirmed, this may happen. And, naturally, 
hal won't grant access to this device as - well, a processor is not a scanner 
if you do not know that it is a scanner.

What I'd like to avoid is to generally assign every device on the SCSI bus 
assigning itself the attribute "processor" the permissions of a "scanner". 
This is why I'd like to realize the list.

The point is now how can I get that list in order to include a set of 
modifications within the fdi file so everyone having a SCSI scanner would 
be "back into live" with the openSUSE distribution (and probably others, 
too).

I mean, there are other ways of getting there (like making the user a group 
member of the group that gets assigned to the device by udev) but this is 
inconsistent and I'd like to prevent end-users from having more work than 
neccessary.

So, I only have one scanner that behaves like this - if you have an idea what 
to check for in oder to find the scanner's behaviour would be fantastic. From 
the sane - sources I only saw that anything like "scanner / processor" is 
accepted by sane - but due to additional rules sane will find out whether it 
is really a scanner or not.

If anyone has a rule of thumb that would (at least) cover the vast majority of 
such devices that would be of huge help for me. I am currently working on a 
patch for sane-desc.c to provide the corresponding information and will send 
it upstream as soon as I know sufficient details.

@Abel: could you kindly provide an example in the sources what you're 
referring to with the INQUIRY command or / and with the sane_start 
references? For example, if I look into hp.c, the sane-start will trigger 
sanei_hp_handle_startScan and things get quite difficult to track.

Thanks again,
take care



Dieter Jurzitza
-- 
-----------------------------------------------------------

                               |
                                \
                 /\_/\           |
                | ~x~ |/-----\   /
                 \   /-       \_/
  ^^__   _        /  _  ____   /
 <°°__ \- \_/     |  |/    |  |
  ||  ||         _| _|    _| _|

if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------Am Dienstag, 6. 
Januar 2009 17:49:56 schrieb abel deuring:
*****
> I think there is no other way than to look into the source code of
> backends for SCSI scanners... IIRC only some Epson and HP scanners
> present themselves as "processors", all others say that they are of type
> "scanner". You can look if a backend checks for the SCSI device type
> after having issued the INQUIRY command, or you can look in the
> sane_start function. If the backend issues the SCSI commands 0x1b (start
> scan) and 0x24 (set window), chances are goog that the device resents
> itself as a scanner, not a processor.
>
> But as I understand it, you need a list of SCSI vendor/model name
> strings for HAL (or udev?) to configure some rules which devices should
> be directly accessible for users. The most simple approach would be to
> parse all *.desc files. This way you will not only get "processor" type
> devices but also all those SCSI scanners that have the SCSI type
> "scanner", but the list is not too long, I think. And I don't think that
> SCSI scanners are any longer manufactured, so we have quite stable list
> of these devices.
*****