Wow! I thought most of your guys are already retired or has millions of $
in retirement fund with no financial burden! I really admire your effort
for spending your precious free time to help the community!
Question: Does libusbx supports hotplug on Linux?? that's very import to
us. I dot not have
Includes Hans' libusb_error_name as is, as well as the new
LIBUSBX_API_VERSION macro. See
https://github.com/libusbx/libusbx/commits/master for more.
Source can be downloaded from:
https://sourceforge.net/projects/libusbx/files/releases/1.0.13/source/
Please try to test as much as you can befor
My bad.
I also prefer avoiding struct duplication, on the grounds that it's
cumbersome and cast are better avoided, but without adding the API
define in libusb.h, that's what I saw as least likely to cause issues.
Especially, I don't see a #define MaxPower bMaxPower as something we'd
want to encou
2012/9/15 Pete Batard :
> On 2012.09.15 09:34, Ludovic Rousseau wrote:
> > I realy do not like this idea. Structures defined by the API should
> > not be redefined by the application. That is the source of more
> > problems later.
>
> We've been through that. This was a typo introduced in libusb
On 2012.09.15 11:35, Hans de Goede wrote:
> BTW I agree that we really need to do a libusb_strerror()
> but I also agree that that should handle translations...
>
> For Linux this can be easily done with gettext, but for
> other platforms it cannot... Either way we should honor
> the LANG / LC_MESS
On 2012.09.15 12:13, Chuck Cook wrote:
> On 09/15/2012 06:31 AM, Hans de Goede wrote:
>> Note that for the code 0 which means success resp. completed we have an
>> overlap in the codes. This is not a problem since normally one would not
>> call libusb_error_name on success / normal completion.
>
On 2012.09.15 11:42, Hans de Goede wrote:
> Not sure if we really need the last 4 bytes
The last word is the whole point. If we go with major minor only (here 1
and 0), this change is fairly useless for the bMaxPower issue, as pre
and post API change will have the exact same value.
Or maybe you
How about returning NO_ERROR for code >= 0
and UNKNOWN_ERROR when code < 0 and doesn't match a defined error
On 09/15/2012 06:31 AM, Hans de Goede wrote:
> Note that for the code 0 which means success resp. completed we have an
> overlap in the codes. This is not a problem since normally one would
I don't know how wise it is to mix the two different namespaces.
//Peter
--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite
Hi,
On 09/15/2012 03:41 AM, Pete Batard wrote:
> I have now pushed the bMaxPower change to mainline. Before I go 1.0.13-rc1
> however, I think I'm warming up to the idea of having a macro in libusb.h,
> that could be used to uniquely identify API changes.
>
> Basically, I'm thinking of something
Hi,
On 09/14/2012 01:49 AM, Pete Batard wrote:
> Besides the USB 3.0/bMaxPower patch, which I'll try to push tomorrow, 2
> other items I would still consider open for 1.0.13 would be:
> - The pkg-config --static and libusb-1.0.pc issue (for which I created
> issue #43: https://github.com/libusb
Note that for the code 0 which means success resp. completed we have an
overlap in the codes. This is not a problem since normally one would not
call libusb_error_name on success / normal completion.
Signed-off-by: Hans de Goede
---
libusb/core.c | 26 +-
libusb/libusb.
2012/9/15 Pete Batard :
> I have now pushed the bMaxPower change to mainline. Before I go 1.0.13-rc1
> however, I think I'm warming up to the idea of having a macro in libusb.h,
> that could be used to uniquely identify API changes.
>
> Basically, I'm thinking of something like:
>
> #define LIBUSBX
13 matches
Mail list logo
