On 2012.06.28 14:14, Xiaofan Chen wrote:
> Enclosed please also find the zip of the html files.
Thanks! That helps a bit.
The two warnings in core are false positives that I think can be fixed
easily by having the following at line 686:
struct libusb_device **devs = NULL;
If you have a chance,
On Thu, 28 Jun 2012 22:09:06 +0800, Xiaofan Chen said:
>You are right. The error message is misleading and indeed the
>linking invocation causes this message.
And indeed, when linking already-compiled object files, why would the linker
care what dialect of C was used in the source files?
But it
On Thu, Jun 28, 2012 at 9:36 PM, Sean McBride wrote:
> On Wed, 27 Jun 2012 20:39:52 +0200, Ludovic Rousseau said:
>>> We're specifying gnu99 in AM_CFLAGS, so I wouldn't expect it to end up
>>> in LD_FLAGS. This is benign, so I'm not sure it's worth spending time on
>>> fixing that.
>>
>>clang is c
On Wed, 27 Jun 2012 20:39:52 +0200, Ludovic Rousseau said:
clang: warning: argument unused during compilation: '-std=gnu99'
>>>
>>> The warning you see is telling you that you are specifying -std=gnu99
>when linking, which does nothing. gcc silently ignores that flag when
>linking, I believe
On 2012.06.27 19:39, Ludovic Rousseau wrote:
> Maybe the solution is to use -std=c99 instead.
If we use c99, then we have to revert to setting the -std option for
each individual toolchain, as we cannot use c99 on cygwin and MinGW for
some time. We used to do that at some stage, but we moved awa
2012/6/27 Pete Batard :
> On 2012.06.18 16:19, Sean McBride wrote:
>> On Sat, 16 Jun 2012 11:49:50 +0800, Xiaofan Chen said:
>>
>>> clang: warning: argument unused during compilation: '-std=gnu99'
>>
>> The warning you see is telling you that you are specifying -std=gnu99 when
>> linking, which do
On 2012.06.17 14:27, Xiaofan Chen wrote:
> Here are the results for clang analyzer under Mac OS X.
>
>CC libusb_1_0_la-core.lo
> ../../libusbx/libusb/core.c:700:4: warning: Function call argument is
> an uninitialized value
> libusb_free_device_list(devs, 1);
>
On 2012.06.18 16:19, Sean McBride wrote:
> On Sat, 16 Jun 2012 11:49:50 +0800, Xiaofan Chen said:
>
>> clang: warning: argument unused during compilation: '-std=gnu99'
>
> The warning you see is telling you that you are specifying -std=gnu99 when
> linking, which does nothing. gcc silently ignore
On Fri, Jun 22, 2012 at 11:11 AM, Alan Ott wrote:
> On 06/16/2012 12:51 PM, Nathan Hjelm wrote:
>> The only reason to use libusb under hidapi on Linux is the lack of
>> an HID API. Its not really a good thing.
>
> I disagree. Linux has hidraw, which is its native HID interface from
> userspace.
>
On 06/16/2012 09:24 AM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen wrote:
>> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm wrote:
>>> Since I expect a majority of libusb's users are looking for portability
>>> so all of HID device users should be directed to use hidapi.
>
On Fri, Jun 22, 2012 at 10:45 AM, Alan Ott wrote:
> On 06/16/2012 09:24 AM, Xiaofan Chen wrote:
>> On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen wrote:
>>> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm wrote:
Since I expect a majority of libusb's users are looking for portability
so al
On Tue, Jun 19, 2012 at 7:24 AM, Xiaofan Chen wrote:
> On Tue, Jun 19, 2012 at 12:05 AM, Pete Batard wrote:
If I use the libusb-1.0.dll MinGW 32bit dll from the binary distribution
with the MinGW.org build xusb.exe and then xusb.exe will work fine.
>>
>> So your MinGW-w64 compiled xusb
On Tue, Jun 19, 2012 at 12:05 AM, Pete Batard wrote:
>>> If I use the libusb-1.0.dll MinGW 32bit dll from the binary distribution
>>> with the MinGW.org build xusb.exe and then xusb.exe will work fine.
>
> So your MinGW-w64 compiled xusb is 32 bit then. It's unlikely to work
> with a 32 bit DLL ot
Pete Batard wrote:
> But wouldn't that require at least one manual installation of the filter
> driver by the user, and therefore equate what we can already provide
> with WCID on non Windows platforms, where one WCID WinUSB driver
> installation is enough the make the platform behave the same w
philip.jos...@microchip.com wrote:
> devices that do not have such descriptors will apparently still
> require an INF file for install purposes.
Yes, that is true. At least the problem is going away in the future.
> Having a single API and "single library" across platforms would
> still provide
On 2012.06.18 18:38, Tim Roberts wrote:
> philip.jos...@microchip.com wrote:
>> Just a note in regards to WinUSB and Windows 8. It would appear that a
>> device will not need to provide an INF as long as it provides Windows
>> specific info in its OS descriptors...
>
> When we talked about this bef
philip.jos...@microchip.com wrote:
> Just a note in regards to WinUSB and Windows 8. It would appear that a
> device will not need to provide an INF as long as it provides Windows
> specific info in its OS descriptors...
When we talked about this before, it was mentioned that it would be
possible
on Windows).
-Original Message-
From: Peter Stuge [mailto:pe...@stuge.se]
Sent: Monday, June 18, 2012 10:09 AM
To: libusb-de...@lists.sourceforge.net;
libusbx-devel@lists.sourceforge.net
Subject: Re: [Libusbx-devel] libusbx v1.0.12 has been released
Hi Philip,
philip.jos...@microchip.com wr
Hi Philip,
philip.jos...@microchip.com wrote:
> the incentive to uncomplicated the user's experience has driven
> many implementers to HID on Windows.
Yes, this is easy to understand. I think by far the best solution to
communicate with HID class devices "manually" is to use HIDAPI.
> Even with
On 2012.06.18 16:00, Xiaofan Chen wrote:
> On Mon, Jun 18, 2012 at 10:49 PM, Xiaofan Chen wrote:
>> On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
>>> It is my pleasure to announce the release of libusbx v1.0.12.
>>>
>>
>> I found a strange problem under XP 64bit with MinGW.org toolchain.
>>
One of the major factors in using HID in unorthodox ways is that there
is no need for the Windows INF/driver install business. This has always
been a potential problem with a customer's machine (permissions and the
like). I agree that many devices using this class might be better served
using bulk,
On Sat, 16 Jun 2012 11:49:50 +0800, Xiaofan Chen said:
>clang: warning: argument unused during compilation: '-std=gnu99'
>make[2]: Nothing to be done for `all-am'.
>
>-std=gnu99 warning does not seem to be a problem to me.
>When using Apple's llvm based gcc 4.2.1 (default) and the
>Apple gcc 4.2.1
On Mon, Jun 18, 2012 at 10:49 PM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
>> It is my pleasure to announce the release of libusbx v1.0.12.
>>
>
> I found a strange problem under XP 64bit with MinGW.org toolchain.
> On the other hand, I am not so sure if this is a
On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
> It is my pleasure to announce the release of libusbx v1.0.12.
>
I found a strange problem under XP 64bit with MinGW.org toolchain.
On the other hand, I am not so sure if this is a real issue since there
is doubt whether XP 64bit officially sup
On Sat, Jun 16, 2012 at 5:28 PM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 3:22 AM, Pete Batard wrote:
>> I don't think I recompiled at level 4 since last time we tried it in
>> libusb-devel, which was probably more than a year ago.
>> I have now added this item as another task for for the 1.
On Sat, Jun 16, 2012 at 11:49 AM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
>> It is my pleasure to announce the release of libusbx v1.0.12.
>
> Great.
>
> Since you mentioned clang quite a bit, so I tried to build
> this one under Mac OS X with Apple's clang compi
On Fri, Jun 15, 2012 at 05:39:58PM -0600, Nathan Hjelm wrote:
> There are two seperate issues here:
> 1) whether or not vendors should be abusing the HID interface to
> bypass problems with the Windows driver model, and
> 2) whether or not these devices should be accessed with libusb.
>
> Let m
On Sat, Jun 16, 2012 at 9:19 PM, Xiaofan Chen wrote:
> On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm wrote:
>> Since I expect a majority of libusb's users are looking for portability
>> so all of HID device users should be directed to use hidapi.
>
> Actually hidapi can benefit from the libusb's
On Sat, Jun 16, 2012 at 7:39 AM, Nathan Hjelm wrote:
> Since I expect a majority of libusb's users are looking for portability
> so all of HID device users should be directed to use hidapi.
Actually hidapi can benefit from the libusb's HID backend as well.
You can see that HIDAPI has a libusb-1.0
On Sat, Jun 16, 2012 at 3:22 AM, Pete Batard wrote:
> On 2012.06.15 19:56, Orin Eman wrote:
>> I compiled at warning level 4 with Visual Studio 2010. There is a lot
>> of noise...
>
> Good point.
>
> I don't think I recompiled at level 4 since last time we tried it in
> libusb-devel, which was pr
On Sat, Jun 16, 2012 at 2:08 AM, Pete Batard wrote:
> It is my pleasure to announce the release of libusbx v1.0.12.
Great.
Since you mentioned clang quite a bit, so I tried to build
this one under Mac OS X with Apple's clang compiler
and it seems to be okay.
CC=clang ./configure --enable-exampl
Nathan Hjelm wrote:
> As I said I will not add nor support IOHID access for libusb on OSX/Darwin
This special case HID class code which was removed from libusb long
ago and now added back into libusbx by Pete didn't belong in libusb
in the first place, and I think it will remain unique to libusbx.
On Fri, Jun 15, 2012 at 12:22 PM, Pete Batard wrote:
> On 2012.06.15 19:56, Orin Eman wrote:
> > I compiled at warning level 4 with Visual Studio 2010. There is a lot
> > of noise...
>
> Good point.
>
> I don't think I recompiled at level 4 since last time we tried it in
> libusb-devel, which wa
On 2012.06.16 00:39, Nathan Hjelm wrote:
> There are two seperate issues here:
> 1) whether or not vendors should be abusing the HID interface to bypass
> problems with the Windows driver model, and
> 2) whether or not these devices should be accessed with libusb.
>
> Let me address the second
On Jun 15, 2012, at 3:59 PM, Pete Batard wrote:
> On 2012.06.15 22:25, Nathan Hjelm wrote:
>> Did you really put that HID junk back in there? This is a bad idea. HID
>> users SHOULD NOT be using libusb and I will not add this IOHID support
>> to the Darwin backend.
>
> That's fine, we're not goi
On 2012.06.15 22:25, Nathan Hjelm wrote:
> Did you really put that HID junk back in there? This is a bad idea. HID
> users SHOULD NOT be using libusb and I will not add this IOHID support
> to the Darwin backend.
That's fine, we're not going to force you to do something you're not
comfortable wit
On Jun 15, 2012, at 12:08 PM, Pete Batard wrote:All, It is my pleasure to announce the release of libusbx v1.0.12. In terms of bugfixes and new features, this new version brings the following improvements: * Fix a potential major regression with pthread on Linux * Fix missing thread ID from deb
On 2012.06.15 19:56, Orin Eman wrote:
> I compiled at warning level 4 with Visual Studio 2010. There is a lot
> of noise...
Good point.
I don't think I recompiled at level 4 since last time we tried it in
libusb-devel, which was probably more than a year ago.
I have now added this item as anoth
On Fri, Jun 15, 2012 at 11:08 AM, Pete Batard wrote:
> All,
>
> It is my pleasure to announce the release of libusbx v1.0.12.
>
> In terms of bugfixes and new features, this new version brings the
> following improvements:
> * Fix a potential major regression with pthread on Linux
> * Fix missing
All,
It is my pleasure to announce the release of libusbx v1.0.12.
In terms of bugfixes and new features, this new version brings the
following improvements:
* Fix a potential major regression with pthread on Linux
* Fix missing thread ID from debug log output on cygwin
* Fix possible crash when
40 matches
Mail list logo
