Re: [Libusbx-devel] libusbx v1.0.14

On Mon, Oct 1, 2012 at 8:06 AM, Pete Batard wrote: > On 2012.09.30 01:04, Chuck Cook wrote: >> Remove the dependency on WinUSB and the other dlls. > > Removing the WinUSB dependency would be a cool project, but it would > basically mean reverse engineering the DLL and creating our own open > sourc

Re: [Libusbx-devel] libusb-win32 driver and libusbx 1.0.14

On Mon, Oct 1, 2012 at 8:23 AM, Pete Batard 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. libusbk

Re: [Libusbx-devel] libusbx v1.0.14

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, s

Re: [Libusbx-devel] libusb-win32 driver and libusbx 1.0.14

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 p

Re: [Libusbx-devel] libusbx v1.0.14

On 2012.09.30 01:04, Chuck Cook wrote: > From my point of view. I would like to see libusb-1.0 go through > another iteration or two. I definitely want that too, and I'm happy that Hans has agreed to do it. If I had more scope, I wouldn't have a problem maintaining both branches, but right now

Re: [Libusbx-devel] libusb-win32 driver and libusbx 1.0.14

On Mon, Oct 1, 2012 at 5:24 AM, Pete Batard 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 > | > ++---

[Libusbx-devel] list_entry() macro null deref

Hi all, libusbx's "list_entry" macro seems to do exactly what is described here: 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 -fcatch-unde

Re: [Libusbx-devel] libusbx v1.0.14

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

Re: [Libusbx-devel] libusb-win32 driver and libusbx 1.0.14

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 wil

Re: [Libusbx-devel] libusbx v1.0.14

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

[Libusbx-devel] libusb-win32 driver and libusbx 1.0.14

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 [libus

Re: [Libusbx-devel] libusbx v1.0.14

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

Re: [Libusbx-devel] libusbx v1.0.14

Hi, On 09/29/2012 01:16 AM, Pete Batard wrote: > On 2012.09.28 08:49, Hans de Goede wrote: >> 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 agree

Re: [Libusbx-devel] libusbx v1.0.14

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 coul