Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from libusb-0.1 to libusb-1.0 #191

Open
GoogleCodeExporter opened this issue Apr 3, 2015 · 23 comments · May be fixed by #673
Open

Switch from libusb-0.1 to libusb-1.0 #191

GoogleCodeExporter opened this issue Apr 3, 2015 · 23 comments · May be fixed by #673
Milestone

Comments

@GoogleCodeExporter
Copy link

libnfc is using the old libusb-0.1 API.
Maybe you can switch to libusb-1.0 instead?

Original issue reported on code.google.com by [email protected] on 12 May 2012 at 8:22

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 12 May 2012 at 8:50

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 10 Oct 2013 at 10:47

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 10 Oct 2013 at 12:20

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

@GoogleCodeExporter
Copy link
Author

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

Should I push the devel branch to the server?

Original comment by [email protected] on 10 Oct 2013 at 6:45

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 13 Oct 2013 at 9:15

Attachments:

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 13 Oct 2013 at 8:22

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 13 Oct 2013 at 9:04

@GoogleCodeExporter
Copy link
Author

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

Original comment by [email protected] on 13 Oct 2013 at 9:10

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 5 Nov 2013 at 3:02

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 5 Nov 2013 at 4:58

@GoogleCodeExporter
Copy link
Author

[deleted comment]

1 similar comment
@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 27 Jan 2014 at 7:31

Attachments:

@GoogleCodeExporter
Copy link
Author

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

Original comment by [email protected] on 27 Jan 2014 at 10:32

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 28 Jan 2014 at 10:00

Attachments:

@GoogleCodeExporter
Copy link
Author

or maybe we could just use libusb_error_name instead ?

Original comment by [email protected] on 28 Jan 2014 at 10:47

@depau
Copy link

depau commented Dec 10, 2017

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?

@neomilium
Copy link
Member

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.

@Hamid-Najafi
Copy link

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

@kuquert
Copy link

kuquert commented Sep 2, 2018

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

@xavave
Copy link

xavave commented Jan 16, 2020

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

@xavave
Copy link

xavave commented Jan 17, 2020

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
https://blog.avxt.fr/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)
image

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

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

below dumpbin /EXPORTS libnfc_libusb10 to check list of functions
image

@ghost
Copy link

ghost commented Jan 3, 2021

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.

@kenspeckle1 kenspeckle1 linked a pull request Jul 11, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants