[sane-devel] Question on SCSI-scanners

abel deuring adeuring at gmx.net
Tue Jan 6 23:28:56 UTC 2009


On 06.01.2009 21:00, Dieter Jurzitza wrote:
> 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.

Right, the hp backend isn't that easy to read ;) It seems from quick
grepping that it issues the INQUIRY command only in one function,
sanei_hp_scsi_new (command data inq_cmd; retunred data in inq_data).

I wrote my mail without actually looking into the relevant source files
and the *desc files... I would have made a moderate bet (say, a few
bottles of wine) that
(1) the *desc files contain the SCSI model and vendor names as returned
by the scanner for the INQUIRY command
(2) each backend would check the vendor and model names returned for the
INQUIRY against a list of known names.

But I am wrong in both cases... You already dicovered that I was wrong
with cklaim (2); for (1), it seems that the HP backend just tries tries
to send an SCL command and to check if the result matches some
expectations in order to decide if the tested device is a supported
scanner... Hence it is not worth the effort to

Anyway, there might be a completely different way to configure HAL. You
can define a rule that a HAL callout script shall be called if a SCSI
device of type processor is detected. In this callout, you call
"scanimage -L" and parse the result to check if one of the detected
scanners has the right SG device file name. If so, you set up the HAL
properties and you can perhaps even set the device file permissions.
(Though that might be better done elsewhere -- ask the HAL folks...)

Abel



More information about the sane-devel mailing list