2012/9/15 Pete Batard p...@akeo.ie:
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
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 hdego...@redhat.com
---
libusb/core.c | 26
Hi,
On 09/14/2012 01:49 AM, Pete Batard wrote:
snip
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:
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
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
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
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
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_MESSAGES
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
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
10 matches
Mail list logo
