sigprocmask does not work for threads but only for forked processes.
Even though a thread-safe version, pthread_sigmask, we do not use it
since using singals with threads is a bad practice. Instead implement
pthread's own cancellation method. Because sane_read blocks when
reader_process is terminated, read_fds is closed and invalidated to
make sane_read abort read and return gracefully.
Not all pthreads implementations use an integer type for pthread_t.
As a matter of fact, POSIX has explicitly withdrawn the requirement
that it must be an arithmatic type.
The musl C library uses a `struct __pthread *` which triggered the
warnings. As of this change, sanei_thread.h works around this by
providing two new macros to help keep this issue out of sight. All
backends have been changed to use these macros.
Adds a "cancelled" flag to the Avision device structure, cleared
in sane_start() and set in sane_cancel(). Test this flag in
wait_4_light() and bail out of the 90-second "wait for the
light to warm up" loop if the scan is cancelled.
Avision scanners can return an additional light-status value meaning
"Transparent Media Adapter back-light is on". Accept this as
equivalent to "on" during the lamp-warmup check prior to starting a
scan. Re-check the light status after sending the window command, as
the light selection might have been changed and a further warm-up
may be required.
The code which tries aggressively to reset/initialize HP 82xx/83xx
Automatic Document Feeders doesn't work well if there's no ADF attached,
because the scanner reports a non-zero ADF model type in this case.
The retry code makes several attempts to initialize the ADF, and then
bails out with an "Operation not supported" error.
Add a new "option skip-adf" which will cause the backend to believe
the "ADF not present" status if that's what the scanner reports.
Fixes#313751
is a nice fairy tale, not more - of course the ponter deref copies the whole
params, and most other packends do it the same way: grep *params *.c, and
consult your local C "assembler frontend" bible, ...
work at all anymore, ... range initilaizer, clobbering paper-length
window bits, ...) introduced over the past years, added support for
newer ASIC gamma table size, added AV220D2+ ID
In the "check if x/y ranges are valid" section of the attach() function, the
enum source_mode was being used instead of source_mode_dim. Since these two
enums are very similar, it's not likely this change will affect anything, but
it does fix the compiler warning.
Previously I had changed the USB ID of this scanner from 0x0a18 back to
0x0a19, believing a previous commit to have been in error since it went
unmentioned in the commit log and duplicated the AV600U Plus scanner's USB
IDs. Rolf Würdemann reported that his AV610 scanner used the 0x0a18 ID and
that it wasn't compatible with the AV_INT_STATUS flag. This commit reverts
my USB ID changes and removes the AV_INT_STATUS flag for the AV610.
However, because this scanner shares its USB ID with the AV600U Plus, it's
possible that the AV600U Plus may require that the AV_INT_STATUS flag be set
in order to function, and thus will break with this change. The code, as
it's written, isn't designed to deal well with the possibility of shared USB
IDs, so I'll wait to see if this actually becomes a problem before embarking
on the lengthy challenge of getting that to work.
Keep track of the number of lines to flip on the reverse page using a negative
number. This uses the ill-advised principle of overloading the meaning of a
variable. Still, it kind of makes sense because these lines are upside down,
so the number should be "upside down" too. Besides, leaving it as a positive
number trips up the code which does page padding, which would require even
more special case code.
Adding sane_reload_devices() to sane_init() required sane_init() to be moved
below the sane_reload_devices() declaration. This restores the original
functionality present before I split the sane_reload_devices() code out of
sane_init() so that it could be called from sane_get_devices().
In a previous patch, I attempted to avoid the possibility of a page remaining
partially inside the ADF unit of a flipping duplex scanner after a scan.
Unfortunately, I introduced a bug where the backside page was accidentally
returned to the client in addition to being cached. This was because I had
a misunderstanding of the post-processing code. This patch skips the post-
processing section altogether, avoiding any unnecessary post-processing and
subsequent unwanted output. The other alternative here was to try to monkey
with the buffers (as is done for LINE deinterlacing), but I felt this would
be harder to implement and even harder to debug in the future.
This fix correctly initializes the AV220-G by querying the firmware.
Added the correct option to support the interlaced duplex format used by
this unit.
Flipping duplex scanners must flip the page in order to scan the back side
of the page. With this option set (which is the default), the page is
flipped back to the original orientation. This is important if you have
a stack of papers. However, if you don't care if every page ends up
flipped compared to how it was loaded, turning this option off might save
some scanning time as the paper won't have to be pulled back through the
ADF mechanism a third time.
Although the flipping duplexer is working, there are some issues relating to
the mechanics of physically flipping paper. First among these is that the
back side of each page is physically scanned in reverse, resulting in an
upside down image. Secondly, the page is held partially in the ADF
mechanism while waiting for the frontend to make another scan request for
the back side image, thus resulting in a stuck page if the frontend fails to
follow through.
My solution to these problems is to treat page flipping as an extreme
extension of interlaced scanning; page level interlacing. This means making
another scan request on behalf of the frontend, and writing the resulting
image to a file as would have been done if the page were line interlaced.
We would have had to write this image to a file anyway to flip the image
right-side up, so we aren't doing any extra work, and technique allows us to
reuse existing code for most of the file handling. The reader_process()
function is called again (recursively) after scanning the front page. We
use the page length of the front side to determine the length of the back,
so that we can write the lines to the file starting at the end and working
towards the beginning (thus flipping the image).
A side effect of this solution was the discovery that the scanner must be
reminded that the paper needs to be re-flipped after each scan, so
set_window() must also be called in reader_process() before starting the
second scan.
Finally, with this change, a minor bug was exposed where frontends were
given the number of lines which would be scanned, which makes sense in
flatbed mode, but does not make sense for an ADF, where the page may be
smaller than the scan window. The code was changed to follow the
specifications, returning -1 in ADF mode (when the length cannot be
determined).
After fixing the duplexer initialization, it became clear that the code was
mirroring the back pages. Since the scanner already supports page
mirroring internally with an optional bit setting (which was already set)
it made the most sense to simplify the code base and remove the variable.
For scanners which potentially have flipping duplexers, only enable
duplexing if there is an ADF present. This leads to the next problem, that
the flipping duplexers (present only on the HP 8200 series AFAIK) don't
always seem to be properly configured when powered up. To solve this some
magical values are written to magical memory locations, and some more
magical status is read back, causing an apparent firmware reset which
blocks communication for a short period of time. See adf_reset() for
details.
Added the AV_ADF_FLIPPING_DUPLEX flag to activate the flipping duplex code
only for models known to have such duplexing ADFs. Prior to this a doubious
huristic was used to guess when the hardware had a flipping duplex unit.
The additional_probe variable protected add_source_mode() and
add_color_mode() from being entered upon subsequent calls. These functions
were patched to not insert duplicate records in this case, removing the
need for the gatekeeper variable.
Until now the code has been changing the frontend supplied pointer to point
to our internal data structure. There are two problems with this. It
orphans the data previously associated with that pointer, which causes a
memory leak. It also gives the frontend the ability to munge our internal
data structure.
The only downside to this change is the possibility that a frontend took the
spec too literally and merely supplies a pointer but does not allocate
storage space for the result. Technically, the spec is a bit vague on this
point, because it does not specifically state who should allocate the
structure, but I feel a reasonable programmer would guess that space
allocation is a frontend obligation.
There was an old TODO in the code which suggests creating an option for using
the paper_length field to detect double feeds in the ADF. I've added it as
an option, but set the default to not use it since it might cause older
scanners to get confused.
I felt that the ehancements group was doing double duity for image tuning and
other more hardware related options. This new group takes ownership of those.
I'm not happy with the name, but that can always be changed.
Olaf Meeuwissen