Hi,
I have an application that prints to stderr when debugging is enabled. It
is multithreaded, so stderr gets a lot of concurrent activity. I have
noticed that libusbx output is often broken up, and looking at the
usbi_log_v() function reveals multiple separate calls to the printf
functions.
AFA
Hi,
Here's two patches to address this, one for usbi_pipe and one for darwin.
Note that return value checking is not being done in Darwin and I wasn't
sure exactly how to handle it, so I'll leave that up to Nathan.
Regards,
Chris
On Fri, Jun 14, 2013 at 7:33 AM, Nathan Hjelm wrote:
>
>
> On
//Example:
//
https://code.google.com/p/picusb/source/browse/lvr_genhid/libusb1_lvrhid4.c
//
https://code.google.com/p/picusb/source/browse/lvr_genhid_mod/libusb1_lvrhid8.c
About the examples you sent Xiofan,
do they need libusb installed on my windows kernel ?
or can i just create a project, in
Thank you guys for your answers,
This community is really active and motivating, i wish i had the skills and
knowledge to contribute,
I admit my thinking sounds nonsense,
I am willing to learn how to use libusbx through small steps,
I should start with the easiest example that i know and worked o
Sorry for the mistake. Don't know why I didn't catch that earlier.-NathanOn Jun 14, 2013, at 07:48 AM, Hans de Goede wrote:Hi, On 06/14/2013 02:43 PM, Xiaofan Chen wrote: > On Fri, Jun 14, 2013 at 5:59 PM, Hans de Goede wrote: >> Hmm, ok, error 11 is EAGAIN, so indeed you're
On Jun 14, 2013, at 02:58 AM, Hans de Goede wrote:Hi, On 06/14/2013 10:19 AM, Chris Dickens wrote: > Hi, > > All looks good now, thanks! > > I actually went with the F_GETFL/F_SETFL approach first, then I saw how poll_posix.c did it with usbi_pipe() and decided to go that way, for consistency. >
Hi,
On 06/14/2013 02:43 PM, Xiaofan Chen wrote:
> On Fri, Jun 14, 2013 at 5:59 PM, Hans de Goede wrote:
>> Hmm, ok, error 11 is EAGAIN, so indeed you're running out of some resource.
>>
>> Can you give the attached patch a try please ?
>>
>
> Great. Your patch fixed the issues I have under Ubuntu
On Fri, Jun 14, 2013 at 5:59 PM, Hans de Goede wrote:
> Hmm, ok, error 11 is EAGAIN, so indeed you're running out of some resource.
>
> Can you give the attached patch a try please ?
>
Great. Your patch fixed the issues I have under Ubuntu Linux.
--
Xiaofan
---
On Fri, Jun 14, 2013 at 6:38 PM, Belkhiria Hamza Yazid
wrote:
> I realized a driverless application for HID communication based on HIDAPI
> using th built in HID windows driver,
>
> I am looking for a driverless solution for HID communication based on
> Libusbx,
> Is it possible ? and in that case
2013/6/14 Belkhiria Hamza Yazid :
> Hello,
Hello,
> I realized a driverless application for HID communication based on HIDAPI
> using th built in HID windows driver,
>
> I am looking for a driverless solution for HID communication based on
> Libusbx,
Why don't you continue with HIDAPI?
Why do y
Hello,
I realized a driverless application for HID communication based on HIDAPI
using th built in HID windows driver,
I am looking for a driverless solution for HID communication based on
Libusbx,
Is it possible ? and in that case could someone direct me on where to start
?
Thanks
Best Regard
Hi,
On 06/14/2013 11:31 AM, Xiaofan Chen wrote:
On Fri, Jun 14, 2013 at 4:08 PM, Hans de Goede wrote:
Hmm, as Nathan has already pointed out this is caused by pthread_create
failing. I think you may be running out of resources and/or hitting
a ulimit.
This may also be related to the udev fd n
On Thu, Jun 13, 2013 at 11:00 PM, Nathan Hjelm wrote:
> ??? It looks like it is failing on pthread_create. That doesn't seem right.
> Can you run under valgrind and see if anything obvious is wrong? I will test
> in a Linux VM when I get home and see if I can reproduce the problem there.
Here are
On Fri, Jun 14, 2013 at 4:08 PM, Hans de Goede wrote:
> Hmm, as Nathan has already pointed out this is caused by pthread_create
> failing. I think you may be running out of resources and/or hitting
> a ulimit.
>
> This may also be related to the udev fd not being non-blocking issue
> Chris Dickens
What better way to show how useful libusb_set_auto_detach_kernel_driver() is,
then to use it in our examples?
Signed-off-by: Hans de Goede
---
examples/fxload.c | 8 +---
examples/xusb.c | 19 +--
libusb/version_nano.h | 2 +-
3 files changed, 3 insertions(+), 26
An error of LIBUSB_ERROR_PIPE simply means the device has no BOS, so don't
log an error to the console for this.
Signed-off-by: Hans de Goede
---
libusb/descriptor.c | 3 ++-
libusb/version_nano.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/libusb/descriptor.c b/libu
Hi,
On 06/14/2013 10:19 AM, Chris Dickens wrote:
> Hi,
>
> All looks good now, thanks!
>
> I actually went with the F_GETFL/F_SETFL approach first, then I saw how
> poll_posix.c did it with usbi_pipe() and decided to go that way, for
> consistency.
>
> int usbi_pipe(int pipefd[2])
> {
>int r
Hi,
On 06/13/2013 08:57 PM, Chris Dickens wrote:
> Hi,
>
> I see from the git log that the hotplug_poll() function was added for
> applications that perhaps handled hotplug notification on their own. Given
> the structure of the new hotplug code, it appears that a context will not be
> successf
Hi,
All looks good now, thanks!
I actually went with the F_GETFL/F_SETFL approach first, then I saw how
poll_posix.c did it with usbi_pipe() and decided to go that way, for
consistency.
int usbi_pipe(int pipefd[2])
{
int ret = pipe(pipefd);
if (ret != 0) {
return ret;
}
ret = fcntl(p
Hi,
On 06/13/2013 08:16 PM, Chris Dickens wrote:
> Hi,
>
> Here's the patch.
Thanks, I've just pushed a somewhat modified version to master, I made 2
changes:
1) Use F_SETFL rather then F_SETFD as according to the manpage for O_NONBLOCK,
F_SETFL should be used. I'm surprised it works with F
Hi,
On 06/13/2013 03:57 PM, Xiaofan Chen wrote:
> On Thu, Jun 13, 2013 at 9:20 PM, Toby Gray wrote:
>> On 13/06/13 14:07, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 06/13/2013 02:41 PM, Xiaofan Chen wrote:
stress test failed with the latest git tree.
1.0.15 release works fine.
mc
21 matches
Mail list logo