Use "Get Preview", and xsane places a rectangular frame around what it
thinks is the relevant portion in the preview image. The user can drag
the sides of this frame to what he prefers. "Scan" then captures just
the area defined by this frame.
Every subsequent scan will use this frame, until
libsane-imagescan.so.1 is in the rpm package at:
http://ftp.gwdg.de/pub/opensuse/repositories/home:/zhonghuaren/Fedora_27/x86_64/imagescan-3.32.0-8.1.x86_64.rpm
but I have only looked to see this file is there. I have not tried it.
Perhaps it will offer you a path forward. I suspect the
Does Olaf Meeuwissen's post at
https://www.mail-archive.com/sane-devel@lists.alioth.debian.org/msg33846.html
help? It describes imagescan as an Epson product.
--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
>Isn't requiring anything beyond the point 1 a teensy bit over-reaching?
Regarding binary stuff, no. If some blob of firmware must be delivered
to the scanner, this firmware must be made available under terms that
allow it to be copied and used by anyone who wishes to have SANE operate
with a
Your udev rules file has no entry for your scanner. Recall that
sane-find-scanner reported:
found USB scanner (vendor=0x04a9 [Canon], product=0x190f [CanoScan])
There should be a udev rule for that device (i.e. one that matches the
vendor and product codes reported by sane-find-scanner). For
>$ sane-find-scanner
>found USB scanner (vendor=0x04a9 [Canon], product=0x190f [CanoScan])
>at libusb:003:002 could not open USB device 0x1d6b/0x0002 at 003:001:
>Access denied (insufficient permissions)
This looks like a permission problem: the user who executed
sane-find-scanner is not allowed
I doubt a gigabit Ethernet connection will make any significant
difference. Data rate from your scanner is dependent on the mechanical
speed of the sensor and scan resolution. If you scan a page 8.5 by 11
inches at 600 pixels per inch resolution with 24 bits per pixel, there is
about 100
"Timed wait" is the final stage when a TCP connection is closed. TCP has
the notion of "maximum segment lifetime" - how long a datagram might
remain somewhere in the network. Before a connection is completely
closed, it remains in the "timed wait" state for twice this maximum
segment lifetime.
>And Fedora22 updated the sane packages to 1.0.25 yesterday!
Also Fedora 21. Therefore, all supported versions of Fedora now use
1.0.25.
--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with
The udevadm program can be very useful when one wants to develop rules
and diagnose udev issues. I have found "udevadm --debug test ..."
particularly useful when I suspect some rule other than the one I intend
has handled a udev event.
--
sane-devel mailing list:
what can be reason for the NET device not to be found
Probably it does not yet exist when scandb starts. Even when startup
scripts are initiated in the proper order, the actual dependency may be
that a network script finishes (or something started by a
network script finishes) before scanbd
Summary: you have four USB scanners; plug them in, and SANE can access
any one of them successfully, but then cannot access any of the three
other scanners.
If you unplug one scanner, then plug it in again, can SANE then use that
scanner? This action should re-create the device's data structures
In my earlier post:
/etc/ldconfig -p
is incorrect, it should be:
/sbin/ldconfig -p
Sorry.
Now it is guess work why the device is temporarily unavailable when
trying to reset it, but replies just fine to the status query to comes
immediately after.
Timing issue? Perhaps the two bytes written to the device start some
action that has not completed before the read request is tried,
Would this explain why the backend works the first time it is called
from within a shell, and then stops working until a new shell is
opened (as I described earlier)?
No... unless the first (successful) operation leaves some data behind
(environment variable?) that causes the second (failed)
Allen has been a steadfast contributor to this list of information and
advice to scanner users, for which it is entirely appropriate to say
Thank you from time to time. Thank you, Allen, for the significant
personal effort you contribute to make SANE and this list a valuable
resource for many
You might try an update to 1.0.22, which is in the Fedora 14 updates
repository. Either use yum update for a general update of your Fedora
system, or yum update sane-backends to update just that.
Alternatively (if your machine has no Internet access) retrieve just the
sane-backends package
Reinhold Kainhofer reinhold at kainhofer.com wrote:
If I use unsigned char*, then I get no warning. However, I fail to see why
using an additional variable makes a difference...
This does not work (b[0] is a pointer to an unsigned char, right?):
unsigned char b[4];
htole32a(b[0], value);
At this point, the only thing i can think of is trying different
distros. I think fedora 13 uses the sane-backends 1.0.21, so if they
have a live cd...
Fedora Version 13 does use 1.0.21:
$ scanimage --version
scanimage (sane-backends) 1.0.21; backend version 1.0.21
but availability of
...scanimage just hangs forever when I try to use it
to scan. scanimage will also hang forever when run with the --help option,
after printing out the help text. It's as if it's trying to print the
scanner name but ran into trouble.
strace is likely to provide some information about why (or, at
Udev rules are never likely to be a stable interface. Hardware
devices and connection mechanisms change over time, therefore new and
different information will be produced; the events recognized and
reported may change as the kernel's structure evolves; additional
function in the applications
The syscall interface is how applications request kernel services. It is
not a general mechanism for the kernel to start userspace applications.
HAL and udev are mechanisms intended to give the kernel a flexible way to
invoke userspace applications when events such as hardware device
connection
a frontend that asks for new, unsupported features, will simply
get an appropriate error code.
Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) alluded
to the problem with this approach when he wrote:
bah- then no front-end will use it, since it is not guaranteed to be
there.
Even if you were to do this, the Oyranos backend still has to connect
to the remote saned instance. If saned is running through inetd, this
just cannot happen.
FTP (File Transfer Protocol) uses passive mode to address this problem.
A similar strategy could solve the inetd issue, but will not
24 matches
Mail list logo
