On 06/08/2015 22:16, Michael Thayer wrote:
Hello Stef,
Stef <stef.dev <at> free.fr> writes:
On 05/08/2015 10:27, Michael Thayer wrote:
Stef <stef.dev <at> free.fr> writes:
in genesys backend build 2508 (commit
4eea901305c9cb66428023c93cbd1a63af8c5fba) I have just pushed fixes for
several opened issues in the bug tracker:
[...]
Sorry to say this, but the issue which I reported previously with the LIDE
210 is not fixed when I apply 09daef4 locally. When I move the usleep() up
to the top of sanei_genesys_test_buffer_empty() however my scanner works
again.
[...]
and when you have an usleep at both places, how does it behave ?
Yes, that works too. Seems slightly hacky. I wonder whether a general
delay, e.g. after writing to a register on a non-super-speed device on a
super-speed port, might be what is needed?
Regards,
Michael
Hello,
thanks for the test report.
Yes this this a hack : one usleep() for your GL847 device, and
another for a GL124 (or USB3?). Since we don't have the timing
requirements of the ASIC, the only thing we can do is trial an error.
Both delays don't add up much when checking for data being available. We
could even wait more between each check.
Regards,
Stef
--
sane-devel mailing list: [email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to [email protected]
