> On 2012.08.09 22:25, Pete Batard wrote:
> OK, first thing I notice is that the timerfd report is output as a
> warning rather than debug, so if your test machine is behaving the same
> way as your other server, it means that you have silenced warnings
> there, which I'd strongly recommend against
Hi Tim,
Sorry for the delay in the replay was on something else ;)
On 2012-07-24, at 12:41 PM, Tim Roberts wrote:
> Kevyn-Alexandre Paré wrote:
>> Here's the code and output of my test. I'm trying to understand what's going
>> wrong! I mean that I'm expecting the callback function "cb_xfr" from
>
> PS: I have now tested the filter driver against a mass storage device
> (i.e. keeping Windows default mass storage driver) and it seems to
> produce the expected results.
>
>
Thanks Pete for the update. We may start testing very soon at my work
(Teradici). What should we expect in terms of mass
David Grant wrote:
> mass storage support?
I guess you already have the following in mind?
http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice
//Peter
--
Live Security Virtual Conference
Exclusive li
Kevyn-Alexandre Paré wrote:
> I at least need to send 2 bytes to the FPGA to receive back a NAK
> in case of a bad 2 first bytes. In case of a proper trame this will
> send a ACK or data packet.
You can simplify your protocol significantly since USB transfers,
aside from isochronous, are a reliabl
On 2012.08.11 01:03, Peter Stuge wrote:
> I guess you already have the following in mind?
>
> http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice
Peter,
As you should be awfully aware, you are replying in the libusbx mailing
list, where, as much as you may wish the contrary, l
Hi David,
On 2012.08.11 00:18, David Grant wrote:
> We may start testing very soon at my work (Teradici).
Great. Please let us know how it goes.
> What should we expect in terms of mass storage support? Were
> you able to transfer files or just have the device show up in device
> manager or in W
On 2012.08.10 08:53, sebasti...@gmx-topmail.de wrote:
> Some weeks ago, at the very beginning of our
> investigation, I had set the LIBUSB_DEBUG variable to 3 on the production
> machines, but it had no impact on the error logging.
This would indicate that the error you got on test is different fr
On 2012.08.10 05:10, Orin Eman wrote:
> I'd do something like the following:
>
> #include
> #if defined(WIN32) && !defined(PATH_MAX)
> #define PATH_MAX (MAX_PATH+1)
> #endif
>
> and use PATH_MAX like you suggested.
I'll try to do that.
Note however that there's going to be a change of plan with