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.
*****
