From: Vishwa S. <vis...@gm...> - 2014-09-16 04:59:07
|
Hi Libusb Community, The libusb 1.0.9 documentation, there is an API to get libusb version. libusb_version * LIBUSB_CALL libusb_get_version(void); But in the libusb 1.0.9 source, libusb.h header file doesn't contains above definition. There is a commit of the same API on 19/04/2012 http://www.libusb.org/changeset/df35117ce58b74fa530baaaccc30adaf432398ea/libusb And the libusb home page promotes to download libusb 1.0.9. Is it the libusb 1.0.9 is the most stable version? If it is not, is there any more stable version of libusb, which is more stable having similar features to libusb 1.0.9? (I cant use libusb 1.0.19 due to my system is using udev version which is not compatible most current libusb). Thank you Vishwa Shanika. |
From: Peter S. <pe...@st...> - 2012-04-20 06:51:46
|
This release has taken much too long to finish, but this also means that it has a long list of bugs fixes and many other improvements. Perhaps the most exciting improvement is the addition of the backend for Microsoft Windows, which closes ticket #1. A very special thanks goes to Pete Batard, Michael Plante, Tim Roberts, Orin Eman, Graeme Gill, and everyone else in the community who help work on the Windows support! Because Windows is a peculiar beast you may encounter some bugs when using this first release with the Windows backend. In that case, please get in touch with the libusb community so that we can help resolve them. File a ticket at http://libusb.org/newticket or let us know via email or on IRC. Visit http://libusb.org/ for all contact details. Another exciting improvement is the new OpenBSD backend, which also works on NetBSD systems. All known downstream bugs and all known severe bugs reported directly to libusb.org have been fixed in this release, so please report new ones! This release would not have been what it is without help, code, reports, and advice from friends like these: Alan Ott, Alan Stern, Brian Shirley, Dave Camarillo, Graeme Gill, Hans de Goede, Hector Martin, James Hanko, Konrad Rzepecki, Ludovic Rousseau, Martin Pieuchot, Mike Frysinger, Orin Eman, Pekka Nikander, Pete Batard, Sean McBride, Sebastian Pipping, Stephan Meyer, Thomas Röfer, Trygve Laugstøl, Vitali Lovich, Xiaofan Chen Thanks! //Peter |
From: Lei C. <Raymond.Chen@Oracle.com> - 2012-04-20 07:07:53
|
First of all, congratulations on the progress! Secondly, what does this mean? libusb is NOT dead? Can libusb and libusbx co-exist on the same system? Will they deliver different .so files? Thanks, Lei Chen -- Not stand for any org. Only speak for myself as a usb user/developer. Peter Stuge wrote: > This release has taken much too long to finish, but this also means > that it has a long list of bugs fixes and many other improvements. > > Perhaps the most exciting improvement is the addition of the backend > for Microsoft Windows, which closes ticket #1. > > A very special thanks goes to Pete Batard, Michael Plante, Tim Roberts, > Orin Eman, Graeme Gill, and everyone else in the community who help > work on the Windows support! > > Because Windows is a peculiar beast you may encounter some bugs when > using this first release with the Windows backend. In that case, > please get in touch with the libusb community so that we can help > resolve them. File a ticket at http://libusb.org/newticket or let us > know via email or on IRC. Visit http://libusb.org/ for all contact > details. > > Another exciting improvement is the new OpenBSD backend, which also > works on NetBSD systems. > > All known downstream bugs and all known severe bugs reported directly > to libusb.org have been fixed in this release, so please report new ones! > > > This release would not have been what it is without help, code, > reports, and advice from friends like these: > > Alan Ott, Alan Stern, Brian Shirley, Dave Camarillo, Graeme Gill, > Hans de Goede, Hector Martin, James Hanko, Konrad Rzepecki, > Ludovic Rousseau, Martin Pieuchot, Mike Frysinger, Orin Eman, > Pekka Nikander, Pete Batard, Sean McBride, Sebastian Pipping, > Stephan Meyer, Thomas Röfer, Trygve Laugstøl, Vitali Lovich, > Xiaofan Chen > > Thanks! > > > //Peter > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Peter S. <pe...@st...> - 2012-04-20 08:01:24
|
Hi, Lei Chen wrote: > First of all, congratulations on the progress! Thanks. A lot of work has gone into this release, and I think it has come out good. > Secondly, what does this mean? libusb is NOT dead? It depends on who you ask. If you ask Pete and perhaps the libusbx developers he spoke for then I guess they will say that libusb is dead, but if you ask me then libusb has never been dead and is certainly not dead now. As Pete mentioned, the 1.0.9 release has taken almost two years, which is an awful long time for a release, but during that time there have also been big changes both in the code and in the project, and while we were busy the bugs had also piled up. I was made co-maintainer by the previous maintainer Daniel some months after he had release 1.0.8, and at that point I should have started making bugfix releases right away, but I really wanted the Windows support to be as good as possible before making a release. There is still a known bug in the Windows backend, but unfortunately it's not so easy to reproduce and there's no really detailed report. > Can libusb and libusbx co-exist on the same system? No, they can not. > Will they deliver different .so files? No. The stated goal of the libusbx project is to replace libusb and thus they use exactly the same filenames, and as announced they may create an incompatible API in the future if they want to. I don't know how that will turn out.. It sounds bad at first, but I think it may be OK, since both libusb and libusbx are the same codebase and they both have similar goals. //Peter |
From: Michael P. <mic...@gm...> - 2012-04-21 04:00:20
|
Peter Stuge wrote: >> > Can libusb and libusbx co-exist on the same system? >> >> No, they can not. I don't think this is technically true with static linking. Depending on whether Pete renames the binaries, it may or may not be true for dynamic, as well. But I'm curious why Lei wants to do this. If it's just a matter of wondering if two applications that use different versions will conflict, that's a valid concern. Regards, Michael |
From: Peter S. <pe...@st...> - 2012-04-21 04:17:23
|
Michael Plante wrote: > >> > Can libusb and libusbx co-exist on the same system? > >> > >> No, they can not. > > I don't think this is technically true with static linking. Ah, yes they can co-exist when statically linked into two different applications. Good point! I understood the question to be about development files and dynamic runtime files, which *can't* co-exist in the same location (e.g. in a system-wide library directory) since libusbx uses the libusb filenames. > But I'm curious why Lei wants to do this. I guess it's about understanding the possibilities with the two libraries. //Peter |
From: Lei C. <ray...@or...> - 2012-04-21 04:37:07
|
On 2012/4/21 11:59, Michael Plante wrote: > Peter Stuge wrote: >>>> Can libusb and libusbx co-exist on the same system? >>> No, they can not. > > I don't think this is technically true with static linking. Depending on You're right. But I don't really care about static linking. > whether Pete renames the binaries, it may or may not be true for dynamic, as > well. But I'm curious why Lei wants to do this. If it's just a matter of > wondering if two applications that use different versions will conflict, > that's a valid concern. I'm concerned about the two libraries. If only one can exist, that will definitely lead to application failing to run if it uses the other library's API. In fact, the current situation will cause user/developer confusion. Is it easy for a user or a program to determine if the existing libusb.so in a system is the one needed? Thanks, Lei Chen > > Regards, > Michael > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: François R. <re...@fr...> - 2012-04-21 08:00:32
|
On 21/04/2012 06:36, Lei Chen wrote: > On 2012/4/21 11:59, Michael Plante wrote: >> Peter Stuge wrote: >>>>> Can libusb and libusbx co-exist on the same system? >>>> No, they can not. >> >> I don't think this is technically true with static linking. Depending on > You're right. But I don't really care about static linking. > >> whether Pete renames the binaries, it may or may not be true for dynamic, as >> well. But I'm curious why Lei wants to do this. If it's just a matter of >> wondering if two applications that use different versions will conflict, >> that's a valid concern. > I'm concerned about the two libraries. If only one can exist, that will > definitely lead to application failing to run if it uses the other > library's API. In fact, the current situation will cause user/developer > confusion. Is it easy for a user or a program to determine if the > existing libusb.so in a system is the one needed? > This looks quite like the ffmpeg vs libav thing to me... Distros will choose which one they package and all apps will have to follow... François. |
From: Lei C. <ray...@or...> - 2012-04-21 05:05:01
|
On 2012/4/21 12:43, Jose Pablo wrote: > >Lei Chen wrote: > > > whether Pete renames the binaries, it may or may not be true for > dynamic, as > > well. But I'm curious why Lei wants to do this. If it's just a > matter of > > wondering if two applications that use different versions will > conflict, > > that's a valid concern. > I'm concerned about the two libraries. If only one can exist, that > will > definitely lead to application failing to run if it uses the other > library's API. In fact, the current situation will cause > user/developer > confusion. Is it easy for a user or a program to determine if the > existing libusb.so in a system is the one needed? > > > I have the same opinion. This is confusing and will lead to desaster. > libusb-0.1 and libusb-1.0 can co-exist why libusb-1.0 and libusbx-1.0 > can not? libusb-1.0 should have a wrapper layer to provide the same API of version 0.1.x, so that to provide backward compatibility. libusb-0.1 is not necessarily needed, even if the binary may still be there. For libusb-1.0 and libusbx-1.0, I think it's because libusbx chooses to use the same library name as that of libusb. Thanks, Lei Chen > > -- > Saludos. > > Santiago 1:5 Y si alguno de vosotros tiene falta de sabiduría, pídala > a Dios, el cual da a todos abundantemente y sin reproche, y le será dada. |
From: Peter S. <pe...@st...> - 2012-04-21 14:14:49
|
Lei Chen wrote: >> libusb-0.1 and libusb-1.0 can co-exist why libusb-1.0 and >> libusbx-1.0 can not? > > libusb-1.0 should have a wrapper layer to provide the same API of > version 0.1.x, so that to provide backward compatibility. Yes, this is the libusb-compat-0.1 library which exists since the beginning of libusb-1.0. It provides the libusb-0.1 API and uses libusb-1.0 for all operations. In fact, using libusb-compat-0.1 may be neccessary in applications where e.g. two different plugins use different libusb API versions. If using libusb-1.0 and libusb-0.1 it is theoretically possible that they can interfere with eachother. When using libusb-compat-0.1 instead of libusb-0.1 then everything goes through libusb-1.0 and all problems are avoided. Thanks //Peter |
From: Xiaofan C. <xia...@gm...> - 2012-04-21 23:44:15
|
On Sat, Apr 21, 2012 at 10:14 PM, Peter Stuge <pe...@st...> wrote: > Lei Chen wrote: >>> libusb-0.1 and libusb-1.0 can co-exist why libusb-1.0 and >>> libusbx-1.0 can not? >> >> libusb-1.0 should have a wrapper layer to provide the same API of >> version 0.1.x, so that to provide backward compatibility. > > Yes, this is the libusb-compat-0.1 library which exists since the > beginning of libusb-1.0. > > It provides the libusb-0.1 API and uses libusb-1.0 for all > operations. In fact, using libusb-compat-0.1 may be neccessary in > applications where e.g. two different plugins use different libusb > API versions. If using libusb-1.0 and libusb-0.1 it is theoretically > possible that they can interfere with eachother. Could yo elaborare? This is an interesting point now that OpenOCD has this situation where some USB Jtag device use libusb-1.0 and the others use libusb-0.1 or libusb-compat-0.1. And Debian/Ubuntu still ship with libusb-0.1. > When using > libusb-compat-0.1 instead of libusb-0.1 then everything goes through > libusb-1.0 and all problems are avoided. -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2012-04-20 09:47:02
|
On Fri, Apr 20, 2012 at 4:01 PM, Peter Stuge <pe...@st...> wrote: > Hi, > > Lei Chen wrote: >> First of all, congratulations on the progress! > > Thanks. A lot of work has gone into this release, and I think it has > come out good. Yes this is great. I can see you have done a lot in the past two days judging from the commits. http://git.libusb.org/?p=libusb.git;a=shortlog;js=1 It is good that libusb and libusbx are now kind of in the same starting point now. >> Secondly, what does this mean? libusb is NOT dead? > > It depends on who you ask. If you ask Pete and perhaps the libusbx > developers he spoke for then I guess they will say that libusb is > dead, but if you ask me then libusb has never been dead and is > certainly not dead now. As far as I am concerned, I will not say libusb is dead. But I will not agree with your approach with regard to release. Even though it comes out quite well but it really takes too long time. Hopefully you can change your ideas about release by a little bit. libusb is not a big project and no need to come out with a release every 3 months like Linux, 6 months is fine, or even one year can be accpetible, but two year is really too long. > As Pete mentioned, the 1.0.9 release has taken almost two years, > which is an awful long time for a release, but during that time there > have also been big changes both in the code and in the project, and > while we were busy the bugs had also piled up. That is exact the problem. > I was made co-maintainer by the previous maintainer Daniel some > months after he had release 1.0.8, and at that point I should have > started making bugfix releases right away, Others and I actually suggested you to come out a bug fix release without Windows so as not to delay the bug fixes for Linux and Mac OS X users... > but I really wanted the > Windows support to be as good as possible before making a release. Many of us suggested to flag it as experimental and released it early... > There is still a known bug in the Windows backend, but unfortunately > it's not so easy to reproduce and there's no really detailed report. Not so sure about what the bug you are referring to. But sure there are bugs in the Windows backend, or the other backend (Mac OS X, Linux and OpenBSD/NetBSD). >> Can libusb and libusbx co-exist on the same system? > > No, they can not. > >> Will they deliver different .so files? > > No. The stated goal of the libusbx project is to replace libusb and > thus they use exactly the same filenames, and as announced they may > create an incompatible API in the future if they want to. > > I don't know how that will turn out.. It sounds bad at first, but > I think it may be OK, since both libusb and libusbx are the same > codebase and they both have similar goals. libusbx 1.0.x series will be drop-in replacement for libusb. http://www.libusbx.org/ libusbx and libusb-1.0 may well diverge in the future. http://sourceforge.net/apps/trac/libusbx/roadmap One difference will be the attitude towards HID device. libusbx aims to support the use of libusbx for USB HID device, at least for Windows, and then probably Mac OS X. It may be difficult for OpenBSD and NetBSD though since they do not export a ugen interface like FreeBSD 9 for generic USB HID device. But that will not cause incompatible API. After the Windows backend integration and OpenBSD/NetBSD support, the next big thing is probably Hotplug. http://sourceforge.net/apps/trac/libusbx/roadmap -- Xiaofan |
From: Peter S. <pe...@st...> - 2012-04-20 10:21:22
|
Xiaofan Chen wrote: > As far as I am concerned, I will not say libusb is dead. But > I will not agree with your approach with regard to release. > Even though it comes out quite well but it really takes too > long time. Hopefully you can change your ideas about > release by a little bit. libusb is not a big project and no need > to come out with a release every 3 months like Linux, 6 months > is fine, or even one year can be accpetible, but two year is really > too long. Yes, I completely agree. As you say the project is not so big, so I think it's OK to also have releases based on features rather than on dates, because if there are no important changes which have come in during the 6 months then might as well wait another few months. And on the other hand if there's some important change then it's fine to do a release even if the last one is only one month old. I think it makes sense to be flexible with the schedule here. > > I was made co-maintainer by the previous maintainer Daniel some > > months after he had release 1.0.8, and at that point I should have > > started making bugfix releases right away, > > Others and I actually suggested you to come out a bug fix release > without Windows so as not to delay the bug fixes for Linux and > Mac OS X users... Yes, and I think it would have been the right move. But I really wanted the Windows support in the next release. Anyway, now it's time to look ahead. > > There is still a known bug in the Windows backend, but unfortunately > > it's not so easy to reproduce and there's no really detailed report. > > Not so sure about what the bug you are referring to. Unfortunately I also don't have much information. Enumeration simply does not find all devices sometimes. //Peter |
From: Ludovic R. <lud...@gm...> - 2014-09-16 08:37:34
|
2014-09-16 6:58 GMT+02:00 Vishwa Shanika <vis...@gm...>: > Hi Libusb Community, Hello, > The libusb 1.0.9 documentation, there is an API to get libusb version. > libusb_version * LIBUSB_CALL libusb_get_version(void); > > But in the libusb 1.0.9 source, libusb.h header file doesn't contains > above definition. > There is a commit of the same API on 19/04/2012 > http://www.libusb.org/changeset/df35117ce58b74fa530baaaccc30adaf432398ea/libusb > > And the libusb home page promotes to download libusb 1.0.9. Is it the > libusb 1.0.9 is the most stable version? The latest stable version is 1.0.19 The web site has changed. It is now at http://libusb.info/ Bye -- Dr. Ludovic Rousseau |
From: Xiaofan C. <xia...@gm...> - 2014-09-16 09:59:53
|
On Tue, Sep 16, 2014 at 12:58 PM, Vishwa Shanika <vis...@gm...> wrote: > > If it is not, is there any more stable version of libusb, which is > more stable having similar features to libusb 1.0.9? (I cant use > libusb 1.0.19 due to my system is using udev version which is not > compatible most current libusb). Maybe you can tell us why you can not use libusb 1.0.19 because of udev version. What if you disable udev? If you still have issue, you can try libusbx 1.0.15 which is the last version without hotplug. https://github.com/libusb/libusb/blob/master/ChangeLog -- Xiaofan |
From: David A. <da...@18...> - 2014-09-16 11:42:35
|
Hi Xiaofan, Vishwa is using Linux implementation on i.MX287 processor see Libusb Asynchronous transfers timeout not happening thread - http://sourceforge.net/p/libusb/mailman/message/32836043/. There could be some'features' in the implementation. David -----Original Message----- From: Xiaofan Chen [mailto:xia...@gm...] Sent: Tuesday, September 16, 2014 11:00 AM To: Vishwa Shanika Cc: Libusb Mailing List Subject: Re: [libusb] libusb-1.0.9 On Tue, Sep 16, 2014 at 12:58 PM, Vishwa Shanika <vis...@gm...> wrote: > > If it is not, is there any more stable version of libusb, which is > more stable having similar features to libusb 1.0.9? (I cant use > libusb 1.0.19 due to my system is using udev version which is not > compatible most current libusb). Maybe you can tell us why you can not use libusb 1.0.19 because of udev version. What if you disable udev? If you still have issue, you can try libusbx 1.0.15 which is the last version without hotplug. https://github.com/libusb/libusb/blob/master/ChangeLog -- Xiaofan ---------------------------------------------------------------------------- -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ libusb-devel mailing list lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Vishwa S. <vis...@gm...> - 2014-09-17 04:54:48
|
Thank you all. Libusb 1.0.15 is great. I could resolved problems in Libusb 1.0.9 by switching to Libusbx 1.0.15. As mentioned by David Ainslie, the reason for searching for more stable version libusb similar to 1.0.9, to avoid not proper working of asynchronous transfers. libusbx 1.0.15 is great in the asynchronous transfers, no issues in timeout. Thank you once again. On Tue, Sep 16, 2014 at 5:13 PM, David Ainslie <da...@18...> wrote: > Hi Xiaofan, > > Vishwa is using Linux implementation on i.MX287 processor see Libusb > Asynchronous transfers timeout not happening thread - > http://sourceforge.net/p/libusb/mailman/message/32836043/. > > There could be some'features' in the implementation. > > David > > -----Original Message----- > From: Xiaofan Chen [mailto:xia...@gm...] > Sent: Tuesday, September 16, 2014 11:00 AM > To: Vishwa Shanika > Cc: Libusb Mailing List > Subject: Re: [libusb] libusb-1.0.9 > > On Tue, Sep 16, 2014 at 12:58 PM, Vishwa Shanika <vis...@gm...> > wrote: >> >> If it is not, is there any more stable version of libusb, which is >> more stable having similar features to libusb 1.0.9? (I cant use >> libusb 1.0.19 due to my system is using udev version which is not >> compatible most current libusb). > > Maybe you can tell us why you can not use libusb 1.0.19 because of udev > version. What if you disable udev? > > If you still have issue, you can try libusbx 1.0.15 which is the last > version without hotplug. > https://github.com/libusb/libusb/blob/master/ChangeLog > > > -- > Xiaofan > > ---------------------------------------------------------------------------- > -- > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce. > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > -- R.K. Vishwa Shanika. |