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
