Bug 11690

Please, see also https://bugs.mageia.org/show_bug.cgi?id=11690

I dusted off a USB Canon LiDE 210 flatbed scanner and connected it to a Mageia 4 system today.

I also saw "libusbx: warning [add_to_flying_list] failed to arm first timerfd (errno 9)"

The solution is to build sane with '--enable-libusb_1_0'.

%configure2_5x \
  --enable-rpath=no \
  --enable-libusb_1_0 \  <-- that 
%if !%{gphoto2_support}
 --without-gphoto2
%endif

The above, plus disabling xHCI (due to my particular scanner) leads to reliable trouble free scanning with a USB scanner.

The long version can be seen at http://users.on.net/~emerson/mga/dokuwiki/scan_print.html#scanning

CC: (none) => rod

This bug is still present in Mageia5 Beta1, and has become more serious: the use of scanimage in scripts has now practically become impossible: calls to scanimage never terminate, with results remaining in unflushed output buffers. In addition to the error message quoted above, the following error message is issued:

libusb: warning [usbi_fd_notification] internal signalling read failed

In Fedora, corresponding bugs have been filed - https://bugzilla.redhat.com/show_bug.cgi?id=1003193 on scanimage. A solid discussion concludes that this is not a bug proper to scanimage, but a consequence of a bug in libusb-compat - https://bugzilla.redhat.com/show_bug.cgi?id=1038566, resolved March 2014.

The Mageia bug follows precisely the same pattern, but it appears that the fix developped for Fedora bug #1038566 has not yet made its way into Mageia. It would be extremely helpful if the existing fix is rapidly applied to Mageia5.

A workaround (create a local executable of scanimage from the tarball: replace exit calls by calls to abort) does allow to nevertheless maintain productive use of Mageia5 - but this is far from a proper and satisfactory solution.

Whiteboard: 4beta1 => 4beta1, still in 5beta1 and more seriou

I tried the solution indicated by Rod Emerson (slightly modify the spec file to force the use of libusb1.0).

That, in fact, solves the problem for scanimage. But it only works, if the in the specfile the building of the epkowa drivers is disabled - they dont compile with libusb1.0) - having sane packages without the frequently used epkowa drivers does not make sense.

I am still trying to see whether it is possible to make the epkowa part of the package work with libusb1.0. Heavy going, I dont even know so far whether the problem is due to packaging, or whether the software of the drivers themselves simply does not work with libusb1.0

But, I think it is important to solve this problem. It is likely that - once Mageia5 is in productive use, users will have problems with scanners.

Substantial progress: the problem why the epkowa drivers do not compile when libusb-1.0 is present is:

 - for this part of the package, the --enable-usb_1_0 option of the %configure macro is not supported and therefore the compiler flags cannot be modified by %configure as this is done for sane-backends (need to add -I/usr/include/libusb-1.0)

 - the %configure macro nevertheless detects the presence of usblib-1.0 and sets the HAVE_USBLIB_1_0 control variable; this, in turn activates the conditional #include <libsub.h> - at least in the procedure sanei/sanei_usb.c, which then fails to compile because it does not find libusb.h.

As a kind of proof of concept, I patched the spec-file by simply appending -I/usr/include/libusb-1.0/ to the definitions of the compiler flags (just before the make of the epkowa software).

A local build of the so modified sane packages works smoothly, when packates are run, the problems at the end of the execution of scanimage disappear. I did what testing I could do: the upgraded packages work flawlessly and I use them in production on Mageia Beta1.

The crude solution of explicitely appending to the declaration of the compiler flags in the spec-file is not very clean - maybe a condition variable should be defined and used for switching between with and without libusb-1.0 support - I would prefer to have advice on what should go into the repositories for cauldron (sane does not have a maintainer).

Timeout. I will now submit the patched package - it is OK as it is, a solution based on adding the --enable-libusb_1_0 option to the %configure macro of the epkowa code would just have been more elegant (but more difficult to do).

sane packages (1.0.24-9.mga5) have been pushed to cauldron

Status: NEW => RESOLVED
Resolution: (none) => FIXED