[sane-devel] HP 8250 ADF doesn't work (patch)

[m. allan noah]

This is perhaps related to a current bug:

https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=312718&group_id=30186

allan

On Mon, Sep 13, 2010 at 9:15 AM, Mike Kelly <mike at piratehaven.org> wrote:
> Hi,
>
> I own an HP 8250 scanner, but the ADF unit doesn't work with sane.  In my
> attempt to find a solution I stumbled upon Debian bug 521410
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521410).  In this bug, it
> is reported that scanning used to work with a previous version of avision.c,
> but that with later versions the ADF stopped working.  With the supplied log
> files in that bug, I decided to try to figure out what changed in the source
> and see if I could return the functionality.
>
> I went through every change in avision.c, going back until June of 2006,
> until I narrowed the problem down to a bit field which used to have one of
> two bits set for all ADF scanners but was later changed to only set the bits
> based on ADF capabilities.  Unfortunately the new code which determines the
> ADF's capabilities excludes this scanner.
>
> There are two core problems:
> 1) The first is that the code is trying to determine the ADF model from the
>   scanner, but the returned value from the scanner is not giving us enough
>   information to determine what the capabilities are for the ADF.
> 2) The second is that the code added to correctly set the scanner bits for
>   2-pass duplex scanners sets a completely different set of bits than
>   before.
>
> About the first problem (detecting the ADF):
>
> The code uses a byte value returned from the scanner labeled "adf_model" in
> the source, but the returned value is a value in the range of 0 to 2.
> Although the code assigns model names to these values, it seems that
> different scanners, with clearly different ADF units, return the same model
> number, so the names can't possibly be valid.  How HP uses this byte is
> unclear, but I suspect that if it is used at all, there is a lookup table to
> determine the ADF features based on the scanner model.  I've looked at debug
> logs for almost all of the supported scanners to support this conclusion.
>
> In fact, having reviewed the documentation of each supported model and its
> ADF capabilities, I have concluded that this byte can be safely ignored,
> and that knowing the base scanner model is sufficient.  I implemented a
> simple flag, AV_ADF_SUPPORTS_DUPLEX, which I have applied to the scanner
> models which support duplex scanning.  If I can believe the comments, this
> change only affects HP scanners.
>
> About the second problem (setting the correct bits):
>
> The original code, for all ADF scanners, set either the duplex (0x10) or
> rear scanner bits (0x08) depending on the selected ADF mode.  The subsequent
> changes do this for only interlaced scanners (aka 1-pass scanners).  The
> code does not set these bits for 2-pass scanners, but instead sets the
> lowest three bits (0x07) of the bitset3 bit field.
>
> The comments suggest that only HP scanners do 2-pass scanning, so I haven't
> looked at other Avision scanners.  In the 2-pass case, the last three bits
> are set, but the duplex mode (0x10) is not.  The comments in the code do not
> lead me to believe that the rear scanning mode exists for HP equipment,
> neither do the photos, debug logs, or documentation of the equipment.  As a
> result, my change is to add setting of the duplex bit (0x10) in addition to
> the last three bits (0x07) (although it should be noted that these were not
> originally set).  I also changed the setting of the bit fields to use the
> SET_BIT macro which seems to be the preferred way to toggle bits.
>
>
> While I was patching the code, I decided to clean up some clever, but
> confusing, code in the set_window() function.  I replaced an intermediate
> value (adf_mode) with references to the underlying core data structure
> (s->source_mode).  This change looks bigger than it is because of I had to
> fix the indenting.
>
>
> Now for the bad news.  I have not tested this code at all.  Unfortunately,
> my scanner is inaccessible to me for the next year, as I've moved overseas
> temporarily.  I can only assume it would work based on the debugging output
> in the aforementioned bug.  I realize it's kind of rude to just dump
> untested code on the group, but I hope you will forgive me as I don't
> actually have the hardware in my possession at the moment.
>
> I've put in a lot of effort to avoid breaking other scanners, but I can't be
> 100% sure that I've been successful.  HP scanners older than the 8200 series
> should be unaffected by these changes, as they don't support duplexing and
> don't enter these code paths.  However, I'm worried about the 8300 series
> scanners because I have not been able to find a debug log for them.  This
> implies that they are working with the current code, but without a debug
> log, I can't know which code path they use.
>
> So, if possible, please test this patch if you have a ScanJet 8200 series
> scanner with an ADF unit.  If you're an owner of a ScanJet 8300 series
> scanner with an ADF unit, please send me a debug log (patch or not).
>
> These are the avision supported HP duplex capable scanners:
> HP ScanJet 8200  (This model didn't ship with an ADF)
> HP ScanJet 8250  (15ppm 2-pass)
> HP ScanJet 8290  (25ppm 2-pass)
> HP ScanJet 8270  (25ppm 2-pass, replaces the 8290)
> HP ScanJet 8300  (This model didn't ship with an ADF)
> HP ScanJet 8350  (25ppm 1-pass)
> HP ScanJet 8390  (35ppm 1-pass)
>
> Thanks,
>
> Mike
> (:
>
> --
> --------Mike at PirateHaven.org-----------------------The_glass_is_too_big--------
>
> --
> sane-devel mailing list: sane-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>             to sane-devel-request at lists.alioth.debian.org
>



-- 
"The truth is an offense, but not a sin"