On Friday 07 August 2015 08:56:44 Stef wrote: > 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.
Problem solved for me too (LIDE110 and 210). Thanks a lot ! -- 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]
