Open GoogleCodeExporter opened 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
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
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:
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
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
[deleted comment]
[deleted comment]
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:
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:
or maybe we could just use libusb_error_name instead ?
Original comment by lucien.j...@gmail.com
on 28 Jan 2014 at 10:47
Original issue reported on code.google.com by
ludovic....@gmail.com
on 12 May 2012 at 8:22