Bugzilla – Bug 596411
Scanbuttond can't find usb scanner, problem with libusb compatibility library
Last modified: 2019-02-26 10:11:50 UTC
Created attachment 354223 [details] Extracts from system logs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.8) Gecko/20100204 SUSE/3.5.8-0.1.1 Firefox/3.5.8 Scanbuttond is a daemon that listens for button presses from a USB scanner and runs a script (buttonpressed.sh) when a press is detected. It uses libusb (not sane) to inter-act with the scanner. I have successfully used scanbuttond with a number of previous versions of openSUSE but it won't work with 11.2. With 11.2, it doesn't respond to button presses and never runs the script. The logs show the daemon starts and loads its required back-ends but that it cannot find the installed USB scanner. I have tried the 2 binary versions of scanbuttond (from the repositories) and also compiled from source. The results are the same in each case; scanner not detected so no response to button presses. I should add that the scanner itself is correctly identified by both scanimage -L and lsusb, and scans perfectly using Skanlite or Xsane. I now find that down-grading from the standard libusb-compat (libusb-0_1-4-0.1.13-2.2.x86_64 I think) to the older libusb-0_1-4-0.1.12-140.1.x86_64 (per bug #559697) fixes the problem. The daemon finds the scanner and properly detects any button presses. It seems very likely that scanbuttond relies on a feature from the original libusb0 that is not properly replicated in the compatibility library for libusb1. Reproducible: Always Steps to Reproduce: 1. Install scanbuttond 2. Press a scanner button 3. Actual Results: Nothing happens - logs show scanner not detected. Expected Results: buttonpressed.sh script should run
I am not at all an USB expert but just noticed "down-grading ... libusb-compat ... per bug #559697" which makes it really look like a duplicate. *** This bug has been marked as a duplicate of bug 559697 ***
Hmmm ... don't think so. I'm no usb expert either, but I had read through bug #559697 fairly carefully before making this bug report. Bug #559697 (and #559724) relate to the inability of the libusb compatibility library to properly handle the transfer of the large blocks of data generated by a scanner during the scan process. The bug I reported (#596411) relates to the inability of a previously working application to even detect the presence of a scanner. It has nothing to do with the transfer of large data blocks. The fact that a work round can be had by using the older library, does not mean they are duplicates. It simple means neither problem was present in the older library. Please re-open this bug.
O.k. - I think a libusb expert should have a look...
hmm.
First try to upgrade of all libusb1 packages from http://download.opensuse.org/repositories/hardware/openSUSE_11.2/ If it works, it is fixed. If not: Please provide debugging data: 1) Install libusb0 library from: http://download.opensuse.org/repositories/hardware:/libusb0:/debug/openSUSE_11.2/ Then set USB_DEBUG=255 variable: export USB_DEBUG=255 and run your application, redirecting output to file. 2) Install libusb1 libraries from: http://download.opensuse.org/repositories/hardware:/debug/openSUSE_11.2/ Then set USB_DEBUG=255 variable: export USB_DEBUG=255 and run your application, redirecting output to file. Then provide both outputs. I need to compare them and find what is happening. Note: Bug 559697 was analyzed, but the fix is pretty complex and not yet written.
Created attachment 354853 [details] Debug output for libusb0
Created attachment 354855 [details] Debug output for lobusb1
(In reply to comment #6) Thanks for that. As requested, I have taken the following steps:- 1. Upgraded the libusb1 packages i.e. libusb1 to 1.0.6-7.2-x86_64 and libusb-compat to 0.1.13-7.1-x86_64. Doesn't work. 2. Installed libusb0 debug library (0.1.12-143.1-x86_64, libusb1 as above). Works. Output attached as libusb0.debug.log 3. Installed libusb1 debug libraries (libusb1 to 1.0.6-10.2-x86_64, libusb-compat to 0.1.13-9.1-x86_64). Doesn't work. Output attached as libusb1.debug.log. There is minimal output from the libusb1 debug run - don't know if that's good or bad. Please let me know if there is anything else I can provide.
scanbuttond/libusbi.c defines some functions with names that clash with lubusb-compat (libusb_init, libusb_open, libusb_close). Those must be renamed.
(In reply to comment #10) > scanbuttond/libusbi.c defines some functions with names that clash with > lubusb-compat (libusb_init, libusb_open, libusb_close). Those must be renamed. Hey, many thanks for that. I thought it was all dead and forgotten.
> Hey, many thanks for that. I thought it was all dead and forgotten. You're welcome. Yeah, I thought the same, but my father was so furious about the scan/print button not working, I had to waste my day solving this issue. And since I claim I use OSS so I can fix issues, I have to justify that. Now that I solved that, I have to figure out why scanimage is waiting for a minute after scanning a page. :( Anyway, I try to contact the project author to have this project alive again.
(In reply to comment #12) Good luck with your scanimage problem. Let me know if I can add my support to convince the project author that the project is still relevant.
Many thanks for your research. Well, it should have impact on the libusb-compat itself. If libusb-compat hides its symbols, then the clash will not happen. But I am not sure whether it is possible with libusb-1 symbols.
Andreas, could you advise with this issue? We need to link against libusb-0.1.so.4 that needs symbols from libusb-1.0.so.0. But we need to make symbols from libusb-1.0.so.0 invisible for the application that links to libusb-0.1.so.4. Is something like that easily possible or do we need to play with dlopen("libusb-1.0.so.0", RTLD_LOCAL) and dlsym() wrappers? This partial issue can be worked around by modifying of the application source code. But libusb is a LGPL application and it is used by many proprietary programs. As libusb0 did not define symbol libusb_open, such application could use it for its own function. After migration to libusb-compat, such application stops to work.
I have no quick idea.
easiest way i proably to port it to libusb1 ? i did this for libgphoto2 and libmtp, so if its not too hard here I could try.
where is the source of this scanbuttond= ;)
Marcus Meissner: I agree. But there is many closed source applications using libusb0, that will never be ported to libusb1. It would be nice to emulate libusb0 in libusb-compat as well as possible.
Marcus Meisner: Its easy to fix scanbuttond. Simply find and rename all instances of libusb_init, libusb_open and libusb_close in the source code. (Per comment 10 above). I renamed them as sb_libusb_init, sb_libusb_open, sb_libusb_close, recompiled and everything works perfectly again. The source code is on SourceForge but there doesn't seem to be any recent activity. I don't know the knowledge to go any further but can let you have my patched source. It would seem to me that this is just a bandaid though and it would be much cleaner if the original problem could be fixed.
Created attachment 623750 [details] libusb-dl.h for inclusion from core.c I got an idea: Load libusb1 by dlopen("libusb-1.0.so.0", RTLD_NOW|RTLD_LOCAL); and bind symbols during library initialization. I just listed all calls and made specially crafted include file. If I include it in core.c, I can remove -lusb-1.0 (well, I have to add -ldl, so it is theoretically possible to introduce new clashes against libdl. But it is much less probable. Now I have to modify the build system to make the solution upstream-able. To make easy proof of concept, I took testlibusb.c from libusb0 test dir, renamed print_device to libusb_open, and started with my new libusb. Before: SIGSEGV After: Works
Final patch sent to the upstream: https://sourceforge.net/p/libusb/mailman/message/33485838/
libusb-compat upstream accepted the proposed fix. Commit number: b6f5a2fe12ca19d658d7180e106254b31cf1f8f5. But it was not the latest version which is used in openSUSE for 2 years. It was a version with regression. The regression was fixed by eaed7b8f11badaf07a91e07538f6e8842f59eaab in a different way than I did it. I just contacted the patch author. If libusb upstream decides to keep the older version (which is less hacky, but insufficient), I'll use the upstream version in Factory as well.
Anyway, this is fixed.