search

marcus905 / libnfc

Automatically exported from code.google.com/p/libnfc
GNU Lesser General Public License v3.0
0 stars 0 forks source link

Switch from libusb-0.1 to libusb-1.0 #191

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 ludovic....@gmail.com on 12 May 2012 at 8:22

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
or maybe we could just use libusb_error_name instead ?

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