In http://www.libnfc.org/community/post/2579/#p2579 you justify the use of 
libusb-0.1 to keep Windows compatibility.

libusbx (http://libusbx.org/) is a fork of libusb to improve Windows support. 
Maybe that could solve the Windows support problems.

Original comment by ludovic....@gmail.com on 12 May 2012 at 8:50

I agree this would be useful as a lot of linux distros are trying to obsolete 
the old libusb and libusbx is now pretty much standard

Original comment by pbrobin...@gmail.com on 10 Oct 2013 at 10:47

Indeed I just realized libusb-1.0 *is* libusbx under Debian.
How confusing...
Any volunteer to attempt the switch in a devel branch?

Original comment by yob...@gmail.com on 10 Oct 2013 at 12:20

• Changed state: Accepted
• Added labels: Priority-High, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

Since I got the (orinigal) idea I can work on it.

Should I push the devel branch to the server?

Original comment by ludovic....@gmail.com on 10 Oct 2013 at 6:45

It will take more time than expected.
Feel free to also contribute patches.

I attach a first patch for m4/libnfc_check_libusb.m4

Original comment by ludovic....@gmail.com on 13 Oct 2013 at 9:15

Attachments:

• 0001-Use-libusb-1.0-instead-of-libusb-0.1.patch

Thanks Ludovic.
I pushed a few changes in a new branch libusb10:
https://code.google.com/p/libnfc/source/list?name=libusb10

I first isolated all libusb API in usbbus.c and removed it from drivers/...
Then your patch
And I added a stripped version of 0.1 compat layer available in libusb-1.0 
sources such that the code can now run with libusb-1.0 \o/

The idea is now to have something already working with libusb-1.0 and to remove 
progressively the compat layer to use native libusb-1.0 API.

Now I've a question:
the current code can somehow be easily compiled either with libusb-0.1 or 
libusb-1.0.
Should we ditch completely libusb-0.1 or is it useful to keep the possibility 
to compile libnfc with libusb-0.1 e.g. for specific platforms??

Original comment by yob...@gmail.com on 13 Oct 2013 at 8:22

Nice idea to make the change progressive.

I don't know a platform where libusb-0.1 is better than libusb-1.0. We may 
forget libusb-0.1 completely.

Original comment by ludovic....@gmail.com on 13 Oct 2013 at 9:04

Ok :-)
It will be much cleaner (in a few commits... when I see the compat layer, APIs 
are quite different)

Original comment by yob...@gmail.com on 13 Oct 2013 at 9:10

A branch is currently running with libusb-1.0:
https://code.google.com/p/libnfc/source/list?name=libusb10

Next steps are:
* Cleaning the extra layers of compatibility currently introduced to use 1.0 
over 0.1 API
* Getting the drivers more independent of libusb API, keeping all that in the 
busses code
* Having a look at the hooks available in 1.0 to disable kernel modules. That 
may be a chance to remove module pn533 when needed rather than blacklisting it 
entirely
* Having a look at Windows as apparently 1.0 is better supported there...

Any help is welcome as I don't know when I'll find enough time to go over this 
entire list...

Original comment by yob...@gmail.com on 5 Nov 2013 at 3:02

• Changed state: Started

To disable/detach a kernel module you can use 
libusb_set_auto_detach_kernel_driver()
http://libusbx.sourceforge.net/api-1.0/group__dev.html#ga1656d6b7272d4c82f842b20
a834b1467

Original comment by ludovic....@gmail.com on 5 Nov 2013 at 4:58

hi,

libusb and libusbx were just merged back together so it will be hopefully 
result in a much better windows support.

here is a patch against libusb10 branch to allow cross-compilation from 
mingw-w64 using libusb/libusbx 1.0.18.

regards

Original comment by lucien.j...@gmail.com on 27 Jan 2014 at 7:31

Attachments:

• libnfc-libusb10-mingw.patch

Thanks, this is now committed 
https://code.google.com/p/libnfc/source/detail?r=5f71a79b56ca64f98900146b103a2f3
61c6dd837&name=libusb10

Original comment by yob...@gmail.com on 27 Jan 2014 at 10:32

hi,

another issue is that the use libusb_strerror is not available for libusb < 
1.0.16.
and should be enable conditionally.

here's another patch

Original comment by lucien.j...@gmail.com on 28 Jan 2014 at 10:00

Attachments:

• libnfc-libusb-conditional-strerror.patch

or maybe we could just use libusb_error_name instead ?

Original comment by lucien.j...@gmail.com on 28 Jan 2014 at 10:47

Hello,
I see this is a very old issue. I see there's still the libusb10 branch in the repository. I was wondering why it hasn't been worked on in years. Do you have any news?

Hello,
@doegox worked on it few years ago, then we worked on other subject.
If you want to update this branch to finalize the switch you are more than welcome !
Feel free to fork libnfc and bring libnfc to libusb 1.0, we will be happy to merge it upstream and made a new major release.

please update libusb. I have trouble to run on Macos, neither ubuntu :(

You can use the compat version of libusb by installing it using mac port
sudo port install libusb-compat
sudo activate libusb-compat

It will make libnfc work

Hello,
Is there a way to get rid of libusbk when using a ACR-122U USB reader with libnfc.dll on windows ?

• with libusb1.0-libnfc ported on Windows, would we still need libusbK driver wrapper when using libnfc.dll on Windows ?
  (when I don't install libusbK on native ACR122U USB driver --> No NFC device found. ; with LibusbK --> NFC device: ACS / ACR122U PICC Interface opened )
  My goal is to be able to use nfc-tools (nfc-list, nfc-mfcclassic, ...) directly with (ACR122U) USB native driver

If anyone is interested, I've tested a solution:
cross compilation of libusb 1.0 then using this version in libnfc fork-libusb10, cross compiled to windows : more infos on my blog post here : http://legacy.averbouch.biz/libnfc-and-nfc-utils-binaries-on-windows-10/#libnfc-libusb10
The answer to my question seems to be : NO --> I still need LibUSBK driver to be able to use nfc-list.exe with my ACR122U
But, when I run libusb10/listdevs.exe the app sees ACR122U even without installing Libusbk driver wrapper. So I guess that the issue (ACR 122U not detected in Libnfc with native driver) comes from the ACR122_USB driver code in libnfc/driver/acr_122usb.c ...--> Is there anyone that can confirm that point please ?

below : test with libusb/listdevs.exe (with or without Libusbk, same detection OK)

below: test with nfc-list and libnfc-libusb10 (WITH LibUsbK installed)

dumpbin /EXPORTS libusb1-0.dll (to check if functions are really the 1.0 ones)

below dumpbin /EXPORTS libnfc_libusb10 to check list of functions

Switching to libusb1.0 would indeed be a favorable option.

Compiling this for iOS devices and the ARM Mac has been a pain as somehow it's still relying on the compat layer, which honestly isn't that much of a problem but still shouldn't be there when a better libusb is available. Would make sense to migrate away from the old library at this point.