Frederik,
I am currently studying the SANE API, so I don't know SANE well yet. I
understand what the problem is, but need to get a little further before I
know how it might be handled. I can't really contribute to the conversation
until I get a little further in study.
I did something similar in a pSOS environment a few years ago where I wrote
a driver that supported multiple Fujitsu scanners. The sets of allowable
resolutions, color depths, etc. were simply keyed off the Vendor and Model
strings that ultimately come from the SCSI Inquiry command. This info was
stored in the SCSI low-level (chip level)driver after the inquiry and could
be handed back to the higher layers when asked for. In this case, I would
expect the SANE backend for Fujitsu scanners to parse the Vendor:Model
strings and then hand back capabilities info from an internally stored
scanner specific set that matches. I would try very hard NOT to use
#ifdef's. Instead I would try to add small amount of switch() logic with
cases for each supported scanner. Should have minimal performance impact.
NOTE: Just received Oliver Rauch email with duplex suggestion... seems at
first like the proper approach. I'll just follow the thread until I know
more...
Thanks for your comments,
Tom Davis
-----Original Message-----
From: Frederik Ramm [mailto:frederik@remote.org]
Sent: Tuesday, February 27, 2001 12:03 PM
To: sane-devel@mostang.com
Subject: Re: Fujitsu fi-4750C Backend Project
Hi Tom,
> In case there is any interest... I have begun writing a backend for the
> Fujitsu fi-4750C scanner. (As this is a low-volume duplex "production"
color
> scanner, I doubt there will be much interest.)
Seems you're in a similar position to me. What do you think you'll do
about the duplex thing? The suggestion to buffer one full page might
be viable... although it's a shame, the Windows software that came
with the scanner supported duplex out-of-the-box.
> Which brings up a general question... Since most of the Fujitsu scanners
> that I have been exposed to in the past have very similar SCSI command
sets,
> shouldn't we try to merge the functionality of the "sp15c", m3096g",
"m3091"
> (re: post by Frederik Ramm), and whatever I produce for the "fi-4750C".
I'd love to. But how do we handle things like different allowable
resolutions, different maximum page sizes, and so on. It wouldn't be a
problem to produce one source code file that, using "#ifdef"s, can
produce three or four different drivers, but what options would we
have if we were to try producing one single driver. An extra
parameter, "--model", maybe - but how would we communicate to the SANE
front-ends that certain settings e.g. of the "resolution" parameter
are only available if the "model" parameter has been set to something
specific? I doubt the current mechanism supports that.
> With that in mind, I will 'try' to make my enhancements to a
> "m3096g" base keeping the original functionality unaffected.
I won't bother since it's all a "draft" anyway. The main work will be
figuring out *how* it works, and once I've got that, I'll be willing
and able to build m3091 support into any clean, combined driver. I
hope .-)
Bye
Frederik
-- Frederik Ramm ## eMail frederik@remote.org ## N57°48.10' W005°40.32'-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Feb 27 2001 - 12:03:59 PST