On Fri, Oct 12, 2012 at 6:03 PM, Xiaofan Chen wrote:
> On Sat, Oct 13, 2012 at 2:15 AM, Orin Eman wrote:
> > Personally, I think it's better to supply native build methods than to
> try
> > to force autotools to work on systems that don't support it.
>
> Me too. So autotools for Linux and BSDs,
john smith wrote:
> Regarding your questions "Who is going to reap the completed URB?"
> I do have a seperated thread (LoopEvent), in a loop,
> call libusb_handle_events_timeout_completed every 100ms.
Why are you using such a short timeout? It generates overhead.
> But I got another "performance
On Sat, Oct 13, 2012 at 2:15 AM, Orin Eman wrote:
> Personally, I think it's better to supply native build methods than to try
> to force autotools to work on systems that don't support it.
Me too. So autotools for Linux and BSDs, XCode for Mac OS X.
What about Windows? What is native under Windo
g...@novadsp.com wrote:
> OK - the link provided by the OP also has an invalid SSL cert ...
The cert is valid, it's just that CAcert who has issued it isn't
included in the long list of CA:s trusted by the web browser.
You can add the CAcert key easily:
http://www.cacert.org/certs/class3.crt
If
Hello Pete
On 12/10/2012 20:00, Pete Batard wrote:
> On 2012.10.12 18:59, g...@novadsp.com wrote:
>> On 12/10/2012 18:38, Peter Stuge wrote:
>>> https://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass
>
> The *proper* link is:
> https://github.com/libusbx/libusbx/wiki/FAQ#wiki-What_ab
On Sat, Oct 13, 2012 at 5:40 AM, Ludovic Rousseau
wrote:
> I provide an Xcode project in my xcode branch at [1]. It was easy to
> setup (on Mountain Lion).
> One remaining problem is that Xcode do not generate a config.h file
> and the code needs one. For now I reuse the one generated by
> ./confi
On Sat, Oct 13, 2012 at 6:43 AM, Peter Stuge wrote:
> Sean McBride wrote:
>> >vs what is currently needed by tarball consumers
>> >
>> >- install Xcode
>>
>> Which you could reduce to zero steps if you provided binaries.
>
> Absolutely! I'm all for providing binaries. What's the good method
> for
Sean McBride wrote:
> >vs what is currently needed by tarball consumers
> >
> >- install Xcode
>
> Which you could reduce to zero steps if you provided binaries.
Absolutely! I'm all for providing binaries. What's the good method
for OS X? Is a .dmg suitable also for a library?
> >CMake unfortun
On 2012.10.12 23:18, Sean McBride wrote:
> I guess the usual "CMake way" would not be to provide VS project
> files with your tarballs at all. The user would use CMake to
> generate the project file for whatever version of VS/Xcode *he has*
Yeah, and my concern is that Windows users who thought
On 2012.10.12 22:06, Sean McBride wrote:
> 3) ???
3) Look at how other software that uses -Wcast-align handles the same issue.
There's probably hardly any piece of significant C code out there that's
not going to cast a char* to struct*, so, if any has switched to using
-Wcast-align, we might
On Fri, 12 Oct 2012 22:58:36 +0100, Pete Batard said:
>> With CMake, you just maintain one set of CMake files, and then it can
>generate a makefile, a VS project, or an Xcode project.
>
>Except it sucks at VS: It can only generate VS project files if you have
>the relevant version of VS installed
On 2012.10.12 22:40, Ludovic Rousseau wrote:
> Maybe this commit [2] can go upstream.
>
> [2]
> https://github.com/LudovicRousseau/libusbx/commit/f8dac33a71a7b056b5186e11cee2aa12f3539be6
I don't have any objection. Anyone sees an issue?
Regards,
/Pete
On 2012.10.12 22:16, Sean McBride wrote:
> With CMake, you just maintain one set of CMake files, and then it can
> generate a makefile, a VS project, or an Xcode project.
Except it sucks at VS: It can only generate VS project files if you have
the relevant version of VS installed (at least that
On Fri, 12 Oct 2012 23:27:40 +0200, Peter Stuge said:
>> On Mac at least, that's now 3 dependencies:
>> - install Xcode
>> - install homebrew
>> - 'brew install' libtool
>>
>> vs
>>
>> - install Xcode
>> - install CMake
>
>vs what is currently needed by tarball consumers
>
>- install Xcode
On Fri, 12 Oct 2012 23:40:46 +0200, Ludovic Rousseau said:
>I provide an Xcode project in my xcode branch at [1]. It was easy to
>setup (on Mountain Lion).
Yes, I created my own too. Easy to setup, as you say. But not so easy to
*maintain*. If a non-Mac user adds/removes a file, he cannot upd
Sean McBride wrote:
> >Homebrew [1] is a very nice tools for installing external tools on
> >Mac OS X.
> >$ brew install libtool
>
> On Mac at least, that's now 3 dependencies:
> - install Xcode
> - install homebrew
> - 'brew install' libtool
>
> vs
>
> - install Xcode
> - install CMake
vs
On Fri, 12 Oct 2012 22:56:16 +0200, Ludovic Rousseau said:
>>>Including a Xcode project may be a solution. I will try to have a look.
>>
>> I suggested it for completeness, but personally I don't think it's a
>good idea.
>
>Why not a good idea?
It just seems like extra work maintaining 3 build sy
Hi all,
When building my own code, where ever I #include libusbx (1.0.12), I get:
libusb.h:1069:9: warning: cast from 'unsigned char *' to 'struct
libusb_control_setup *' increases required alignment from 1 to 2 [-Wcast-align]
libusb.h:1098:39: warning: cast from 'unsigned char *' to 'struct
l
On 2012.10.12 19:55, Sean McBride wrote:
> On Fri, 12 Oct 2012 20:46:45 +0200, Ludovic Rousseau said:
>> Including a Xcode project may be a solution. I will try to have a look.
>
> I suggested it for completeness, but personally I don't think it's a good
> idea.
I'd also vote for XCode rather tha
On 2012.10.12 20:10, Peter Stuge wrote:
> Sean McBride wrote:
>> Where can I find Vitali's CMake support? I'd be interested to know
>> what state it's in...
>
> https://github.com/vlovich/libusb/tree/cmake-support
It's also in my branch. This is the one feature I didn't import into
libusbx when
On 2012.10.12 17:42, Sean McBride wrote:
>> The reasoning is that issues that are not tied to hardware
>> access, such as compilation breaking on a specific platform or even
>> breakage of apps such as usbutils and OpenOCD, are going to be reported
>> fairly extensively compared to ones tied to a s
Sean McBride wrote:
> >> Other than finding and installing 'libtoolize', is there another
> >> way to build?
> >
> >I guess not. Feel free to contribute something.
>
> Where can I find Vitali's CMake support? I'd be interested to know
> what state it's in...
https://github.com/vlovich/libusb/tre
Sean McBride wrote:
> >Note that autotools are requited _only_ for people using the GIT
> >version.
>
> What is the difference? What is included with the "released"
> version that is not included with git, and why?
The difference in this case is that the autotools have been run by
whoever create
On Fri, 12 Oct 2012 19:03:30 +0200, Peter Stuge said:
>> Other than finding and installing 'libtoolize', is there another way
>to build?
>
>I guess not. Feel free to contribute something.
Where can I find Vitali's CMake support? I'd be interested to know what state
it's in...
Cheers,
--
On 2012.10.12 18:59, g...@novadsp.com wrote:
> On 12/10/2012 18:38, Peter Stuge wrote:
>> https://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass
The *proper* link is:
https://github.com/libusbx/libusbx/wiki/FAQ#wiki-What_about_USB_HID_device_support
Peter, you have been warned once
On Fri, 12 Oct 2012 20:46:45 +0200, Ludovic Rousseau said:
>> autotools used to be part of Xcode, but was removed as of 4.3 (March 2012).
>
>You can install the autotools from another Apple package named
>"Command Line Tools".
>See http://apple.stackexchange.com/questions/40759/missing-autoconf-
>
On Fri, Oct 12, 2012 at 9:43 AM, Sean McBride wrote:
> On Mon, 1 Oct 2012 22:01:39 +0100, Pete Batard said:
>
> >Now, if a dependency on CMake is preferable, I'm not closing the door on
> >either (After all, I did add Vitali's CMake support in my branch when he
> >proposed it), but I'd like to hea
Peter
On 12/10/2012 18:38, Peter Stuge wrote:
> g...@novadsp.com wrote:
>> All I really need to do is send a few bytes of configuration data over
>> the control endpoint but can see no way of doing that with the Windows
>> stack in the way ..
>
> Use bDeviceClass 0xff (vendor specific) and install
g...@novadsp.com wrote:
> All I really need to do is send a few bytes of configuration data over
> the control endpoint but can see no way of doing that with the Windows
> stack in the way ..
Use bDeviceClass 0xff (vendor specific) and install the winusb kernel
driver using libwdi in any part of
Sean McBride wrote:
> I just forked libusbx on github and tried to build it. README.git
> says "run either ./autogen.sh or ./bootstrap.sh" but both result in:
>
> libtoolize or glibtoolize was not found! Please install libtool.
>
> autotools used to be part of Xcode, but was removed as of 4.3 (M
On Mon, 1 Oct 2012 22:01:39 +0100, Pete Batard said:
>Now, if a dependency on CMake is preferable, I'm not closing the door on
>either (After all, I did add Vitali's CMake support in my branch when he
>proposed it), but I'd like to hear what others have to say.
I just forked libusbx on github a
Sorry for my delayed reply...
On Mon, 1 Oct 2012 22:01:39 +0100, Pete Batard said:
>- CDash seems to be quite tied up to CMake, whereas we're using
>autotools, and we've seen after Vitali's departure that the demand to
>justify CMake maintenance wasn't really there. I'd rather avoid
>introduc
Blackfin based firmware gets closer to release. I'm out of time to add
composite device support to the ADI driver stack, so by default it is a
mass storage device.
Now, it would be really cool to be able to persuade the gadget to
disconnect, reconfigure and reconnect with a different PID, i.e.
33 matches
Mail list logo
