Giorgio F. Signorini giorgio.signorini at unifi.it writes:
It's more or less reproducible: if I start a new (root) shell session,
the first 'scanimage -L' is successful (debug output scanimage-1.log
attached); all subsequent 'scanimage -L' fail (debug output
scanimage-2.log attached).
Thanks
From: Olaf Meeuwissen olaf.meeuwissen at avasys.jp
Date: Thu, 26 Apr 2012 08:54:22 +0900
Thanks for the logs. In the first log, all device I/O looks fine. In
the second log, the backend indicates that it did not get a reply to the
very first command it sends to the scanner. There
Giorgio F. Signorini giorgio.signorini at unifi.it writes:
From: Olaf Meeuwissen olaf.meeuwissen at avasys.jp
Date: Thu, 26 Apr 2012 08:54:22 +0900
Thanks for the logs. In the first log, all device I/O looks fine. In
the second log, the backend indicates that it did not get a
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,
From: Richard Ryniker ryniker at alum.mit.edu
Date: Thu, 26 Apr 2012 08:02:03 -0400
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
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)
