Chuck Cook wrote:
From my point of view. I would like to see libusb-1.0 go through
another iteration or two.
Sounds like a great opportunity to get more involved. Go for it!
tests with baseline devices which exercise all functions of every API
If you've been using the API then this could
Hi,
On 09/29/2012 01:16 AM, Pete Batard wrote:
On 2012.09.28 08:49, Hans de Goede wrote:
snip
This is all not necessarily disastrous :) But still
we should at least try not to burn through ABI/API incompatible releases
too soon.
Yeah, that's what I want too.
Good then we are in
Hi,
On 09/30/2012 02:04 AM, Chuck Cook wrote:
From my point of view. I would like to see libusb-1.0 go through
another iteration or two. Remove the dependency on WinUSB and the other
dlls. Get as many of the core functions working cross platform as
possible.
We may eventually need to
Hi,
I wanted to use libusb-win32 as driver for libusb-1.0 so I used Zadig
to change the driver for the device from WinUSB to libusb-win32.
However doing just this would fail. For instance xusb was not able to
read the description strings. The logs were saying something like:
libusbx: debug
Building against different libraries with different interfaces on
different platforms is exactly what I want to avoid. One size fits all
would be perfect.
I was looking at the android source the other day and found a early
version of libusb in there. One library that worked on all desktops
Hi Tormod,
The first thing I want to mention, before discussion your issue (which
is something that should have appeared in the ChangeLog, but that I
completely forgot to add), is that support for the libusb-win32 and
libusbK drivers in libusbx is still very EXPERIMENTAL at this stage, and
On 2012.09.30 11:20, Hans de Goede wrote:
On 09/29/2012 01:16 AM, Pete Batard wrote:
The great thing with being a fork is we can afford being unpopular: our
users have exceedingly easy means to switch away from us if they aren't
happy. :)
I disagree strongly here, to me our first and
Hi all,
libusbx's list_entry macro seems to do exactly what is described here:
http://en.wikipedia.org/wiki/Offsetof
In particular, it has undefined behavior according to the C standard, since it
involves a dereference of a null pointer.
After building libusbx with clang and
On Mon, Oct 1, 2012 at 5:24 AM, Pete Batard p...@akeo.ie wrote:
Of course, a nice graphical
presentation of the Windows driver layering would be very welcome :)
1. With libusbK.dll available
libusbx
|
V
libusbK.dll
|
On 2012.10.01 00:57, Xiaofan Chen wrote:
One minor issue, libusb0.dll is not used for libusbK.dll, libusbk.dll
directly talked to libusb0.sys, just like it directly talks to libusbk.sys.
Ok. I was wondering about that as well. Another good job from Travis
then (but then leaving me even more
I agree this list is just way to big. We cannot possibly run all the
different build possibilities on all the different platforms.
Possibly this is the point where I could contribute to the project.
Select a core set of build methods along with software/hardware.
I am not really a programmer,
On Mon, Oct 1, 2012 at 8:23 AM, Pete Batard p...@akeo.ie wrote:
On 2012.10.01 00:57, Xiaofan Chen wrote:
libusbK's inf-wizard (MFC based) does bundle libusbk.dll and libusb0.dll
for both libusb0.sys and libusbk.sys since libusbk.dll and libusb0.dll
work with both libusb0.sys and libusbk.sys.
12 matches
Mail list logo
