On Mon, Apr 05, 1999 at 10:28:01PM -0700, De Clarke wrote:
>
> I edited my microtek2.conf file :
>
> # See sane-microtek2(5) for a description of the options
>
> option dump 1
> option lightlid-35 on
> # option no-backtrack-option on
> scsi * * Scanner
>
>
> so that the 35mm lightlid device option was "on"
> as you see. Just uncommented that line. I turned off
> the scanner, plugged in the lightlid, turned it back on --
> it lit up. Started xscanimage but no source option appears
> in xscanimage as a result of the conf file change and plugging
> in the device.
>
> I then tried to use scanimage manually with the scan-source
> option
>
> scanimage --scan-source TMA microtek2:/dev/scanner
>
> and I got an error message about the scan-source option being
> inactive.
>
> scanimage: attempted to set inactive option scan-source
>
> Umm, is there something else I have to do to activate this
> option? I thought the conf file settings were dynamic. The
> man page says only the dump and strip-height options are
> supported... sad if true, 'cause the whole reason I wanted
> this particular model of scanner was so that I could scan
> slides and negative strips.
>
> In the backend source I see the md_lightlid35 option, which
> seems to be used later in the scan-source option parsing...
> So it looks as though the lightlid-35 option is honoured,
> despite what the man page says... what is the status of
> this option? am I doing something silly, or perhaps not doing
> something obvious?
The Microtek models have several operating modes, for example flatbed, TMA
and automatic document feeder. The TMA mode is used for dedicated
transparency adapters (for example, when you replace the lid of the
scanner by a lid with a builtin lamp), not for this 35mm-adapter.
They also have modes for stripes and slides. When this obscure adapter
came out I thought that the stripe and slide modes could have something
to do with this adapter and invented this lightlid-35 option. Obviously
this is not case.
Normally the attributes of these different modes (for example
the scan area sizes or the data formats between these modes might be
different) can be inquired. But on my own X6 I tried to
inquire the attributes of all possible modes, i.e. all bit combinations,
that could represent such a mode - even the reserved ones - and got
only errors.
Moreover, it is normally possible to determine during runtime whether
a (real) TMA is actually connected to the device. This isn't possible, too,
for this 35mm-adapter. From the backend's point of view this device is
simply not present, whether it is connected or not.
To state it clearly: This 35mm-adapter has nothing to do with the TMA
option of the backend.
Thus all you can do is to put it onto the glass of the scanner and start
a scan from the flatbed...
Considering my own observations this behaviour is consistent with the
behaviour under Windows, but maybe there are models that behave different.
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com