Revised patch looks OK to me too, so I will commit/push along with
previous set.
On 2012.04.20 10:57, Ludovic Rousseau wrote:
Le 20 avril 2012 11:39, Hans de Goedehdego...@redhat.com a écrit :
Any chance you could send patches inline? That makes it much easier
to comment on them when
On 2012.04.20 11:03, Xiaofan Chen wrote:
I will say OS X HID backend is a nice to have feature
but not absolutely necessary, could be in 1.0.13 or 2.0.
Actually, it was stated for 1.0.11 and I moved it to 1.0.12, as I don't
think we'll have much time to look into it. I don't have a problem
On 2012.04.21 09:47, Hans de Goede wrote:
Next, I'd like to pick up the Linux: Search for
/dev/usbdevbus.device USB device special files [1] patch, but
before I do that, I wouldn't mind if the Linux people get a chance to
look at it.
I just reviewed the patch as found in
On 2012.04.23 08:40, Hans de Goede wrote:
I can understand you not being happy with these addons, but without them
code compiled against Peter's version of get_version may crash, so I
strongly
prefer adding them (despite your concerns)
Well, my concerns go a bit further than that.
If we go
On 2012.04.23 18:31, Garret Kelly wrote:
I'll agree with you that end-users and developers may prefer a fork of
a given project, but many modern distributions offer both sides of a
forked package, and even multiple versions of the forked packages in
the case of the JRE. Additionally,_because_
On 2012.04.23 13:15, Michael Plante wrote:
Peter's recently been very accommodating about copying patches that he
probably doesn't want in libusb, and quickly. I don't know if you've
noticed that.
Yeah. Isn't it strange what people will do when they realize that, far
from what they believed
On 2012.05.01 16:52, Uri Lublin wrote:
Only if old backend api is UNSUPPORTED.
This happens when a libusb driver (e.g. WinUSB) is installed
after a device has been setup/discovered (with get_device_list).
---
We want to install libusb driver for USB devices dynamically following a
request
On 2012.04.29 06:42, Arnon Gilboa wrote:
I see that you used wdi_register_logger() in an Hack for wdi logging
section (currenlty disabled).
Can you elaborate on the limitation you found there and if you would
like an enhancement of libwdi's logging facility?
I simply wanted wdi used by the
On 4 May 2012 15:29, Sean McBride s...@rogue-research.com wrote:
Do you necessarily need an integer to display?
I meant integer in the mathematical sense, not the C sense (else I
would have used int).
You could also print the address of the pthread_t struct
Which would be an integer alright,
Now pushed to mainline.
Regards,
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
On 2012.05.04 23:44, Sean McBride wrote:
Wouldn't that mean that OS-X would have different logging from other
platforms?
Seems it already does, no? Not all platforms have mach threads after all.
I'm talking about the log output. With the proposal, all platforms
return an int = the libusb
On 2012.05.06 04:43, Xiaofan Chen wrote:
Also now that libusbx fork is public, so I think it is not
a problem to expose the original fork mailing list.
Except we are going to be busy enough with reinstating HID, adding
topology, setting up gerrit and other stuff, which are all aimed to be
On 2012.05.06 03:39, Xiaofan Chen wrote:
With BSD support becoming a headache, and no official maintainer for the
*BSD backends to help us out, along with the need to go to bugfix release
soon, I propose dropping thread IDs for OpenBSD/NetBSD for the time being,
and just return -1 there.
I
On 6 May 2012 15:32, Xiaofan Chen xiaof...@gmail.com wrote:
I think maybe it is a good idea to extend the discussion
to a bigger group now that libusbx-devel is open to the public.
Which is also what I want. But I also want to make sure that both
sides are represented as they should and I don't
On 2012.05.06 23:56, Peter Stuge wrote:
Then please define full owership.
--8-- http://simple.wikipedia.org/wiki/Copyright
A copyright is a law that gives the owner of a written document,
musical composition, book, picture, or other creative work, the right
to decide what other people can do
On 2012.05.07 00:43, Xiaofan Chen wrote:
So I actually want to get the simple
VID/PID filter done first which you agree in your first reply
that as Segher's suggest is a no brainer, and, IIRC, we used to
have something similar in the 0.1 API, so I'm fine with that.
BTW, there is nothing like
Libusbx v1.0.11 RC1 is now available either from git, or as a source
tarball from:
https://sourceforge.net/projects/libusbx/files/releases/1.0.11/source/
This is the RC for the 1.0.11 bugfix release, that reverts the removal
of critical Windows event handling call, which was introduced in
On 2012.05.07 14:40, Xiaofan Chen wrote:
As per Matin (the author of the OpenBSD backend), you can
use the getthrid() syscall that returns a pid_t.
Great. I'll give it a try and if it works, add it for the release.
Regards,
/Pete
On 2012.05.07 15:47, Pete Batard wrote:
On 2012.05.07 14:40, Xiaofan Chen wrote:
As per Matin (the author of the OpenBSD backend), you can
use the getthrid() syscall that returns a pid_t.
Great. I'll give it a try and if it works, add it for the release.
Seems to require linking against
On 2012.05.08 01:00, Xiaofan Chen wrote:
What did you use to install your OpenBSD platform?
It is the snapshot release, which is more recent
than 5.1 release.
Aha! I think I'll keep testing with the old release for now, so that
between the both of us, we have a slightly more representative
On 2012.05.08 01:10, Xiaofan Chen wrote:
A few warnings under NetBSD 6.0 Beta. Other than that, it
seems to work fine.
CC libusb_1_0_la-openbsd_usb.lo
os/openbsd_usb.c: In function '_sync_control_transfer':
os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer
will break
On 2012.05.08 11:07, Xiaofan Chen wrote:
Martin's answer:
This is normal, you must use an OpenBSD -current in order
to have real threads enable, until 5.1 OpenBSD only has
userland threads.
OK. If possible, can you try the attached patch on your platform and let
me know whether you get a
On 2012.05.08 11:08, Xiaofan Chen wrote:
Sean, maybe it would be an idea for the os dependent code to print a
thread name + id when creating a thread and debugging is enabled,
this way a user can easily find which thread-id is which thread
in the logs?
Maybe this is a good idea.
On that
I'm currently having a look in Trac. The following are the tickets that
I plan to close as fixed with the 1.0.11 release:
o https://sourceforge.net/apps/trac/libusbx/ticket/13
Timestamping in log messages
o https://sourceforge.net/apps/trac/libusbx/ticket/16
Enable support for Linux
On 2012.05.08 12:02, Pete Batard wrote:
Looks like we also could use a space between [function call]
and message in the header.
Disregard. Thunderbird ate the space when replying.
Regards,
/Pete
--
Live Security
Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Thu, 10 May 2012 15:56:51 +0100
Subject: [PATCH] Misc: Separate nano from version.h
* As version.h processed by autotools, the automatic updating of the
nano there can result in unneeded reconfs (eg. after issuing a git
pull, regardless
On 2012.05.11 16:48, Peter Stuge wrote:
I think the proposed API could be simplified. There's a hard upper
limit on the path length (7 ports including the HC) so I would
suggest to drop the path_len input parameter and document that path
must be uint8_t [7] or longer.
With software history
On 2012.05.12 12:55, Peter Stuge wrote:
I was hoping that you would also comment on my API suggestion which
completely avoids this problem. Maybe someone else will.
I don't see how returning numbers represented as a string instead of
actual numbers is that helpful. This translates the actual
So, in summary, the issue is:
- you have developed a custom solution/layer to add hotplug to libusbx,
even as libusbx is going to officially implement the very same feature,
internally, in a manner that is likely to be quite different from yours.
- when using this custom feature/layer, you are
v2, that takes into account what was discussed previously (but still
provides get_parent).
Regards,
/Pete
From 4ff57d754aed031b8b73e161e56064338b4bd06a Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Mon, 14 May 2012 11:44:00 +0100
Subject: [PATCH] All: Add parent and port
On 2012.05.14 14:16, Xiaofan Chen wrote:
The leading inFrom is automatically added by the mailing list
so you can not stop it.
But I am not so sure why your attachment also has the before From
which will cause git am to fail.
Looks like this means I won't be able to please everybody then,
On 2012.05.14 18:44, Peter Stuge wrote:
I don't think that should be neccessary. If replacing the driver does
not lead to a new libusb_device * for the device then I think it is a
bug if the device must be destroyed before accurate state is reported
by calls to _get_device_list().
Installing
On 2012.05.14 18:26, philip.jos...@microchip.com wrote:
We provide two basic interfaces in the above layer (speaking from a Java
point of view): A provider interface and a device interface. The
provider handles getting the device list and keeping it up to date and
notifying any registered
On 2012.05.14 20:21, Uri Lublin wrote:
(I also changed -k option's according to vid:pid of a usb disk I'm
testing with)
The fact that you tested with an usb disk may explain a few things. In
that case, you're _replacing_ an existing driver (mass storage -
WinUSB) rather than installing a new
On 2012.05.14 19:47, Uri Lublin wrote:
When I started the implementation, I was not aware of libusb plans
on supporting hotplug in the near future.
Yeah that's the issue we had with libusb and part of why we forked.
Libusb has been so bottlenecked with issues that should have been dealt
with
On 2012.05.15 01:03, Pete Batard wrote:
Could be that we're
trying to access unref'd and restroyed parent devices on OS-X, hence the
seemingly random outcome.
Yup. Confirmed that some of the parents we're trying to access get
unref'd and destroyed before we attempt to access their data
On 2012.05.18 01:27, dan wrote:
after noon guys im trying to port the ubertooth over to windows and get
it working properly.
Nice.
gcc ubertooth-dump.c ubertooth.c -o ubertooth-dump -llibusb-1.0 -lbtbb
ubertooth.c: In function ‘stream_rx_usb’:
ubertooth.c:124:4: warning: passing argument 6
If you send a request for help to a mailing list, please try to always
reply to the mailing list (libusbx-devel), rather than just the person
who answered your post. Else you are:
1. restricting the number of people who can provide help to just that
person, and cutting out other people who
On 2012.05.18 18:46, dan wrote:
•12:40PM• mossmann Our code compiles fine with libusb 1.0. That's
what we support. If libusbx doesn't support the libusb 1.0 API, then
forget it.
Libusbx does support the 1.0 API.
Currently, unless you're using one of the calls that only libusbx
provides,
On 2012.05.22 10:14, Xiaofan Chen wrote:
However, if Windows always considers a device with 0:0 in the device
descriptor an error, then the Windows backend should discard them.
I believe that Windows always considers a device with 0:0 in the device
descriptor as an error.
Yup. And the
On 2012.05.19 14:54, Xiaofan Chen wrote:
The other test I want to do is to see if I can use this works well
as the backend for HIDAPI or not.
This turns out to be not as easy as I expected so I will not carry
out this test.
That's fine with me. I'm still trying to find time to dig up some of
On 2012.05.22 15:25, g...@novadsp.com wrote:
That seems to be a USB hub. Is it?
http://www.ixitools.com/hwcat/_b8139c20-cf94-11d5-aef7-0002b30625c5_vid_05e3_pid_0608/devinfo19476.html
Good call. It is a hub but it is not showing up as borked in Windows.
I'll ignore it.
We've been seeing that
Fix to reduce the severity of the log message above has now been pushed
to git.
Regards,
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape
Hi Yves,
On 2012.05.22 19:06, Yves Arrouye wrote:
I stumbled upon libusbx when researching whether libusb would support
exposing the concept of a USB Location ID (which I am not sure is part
of a standard, but seems to be widely understood as available on
Darwin/OS X and Windows, and may be
On 2012.05.23 11:25, Xiaofan Chen wrote:
I think the problem is the © '(c)' sign in the headers, I see
2 possible solutions:
1) Stick to ASCII only, so replace '©' with '(c)'
2) Convert the files to UTF-8 in our git repo and tarbals
So what do you think is the best solution?
I vote for
On 2012.05.23 03:17, Yves Arrouye wrote:
I double-checked the actual OS X API (the 32 bits comes from one of
their samples). It seems like the underlying object is actually an
OSNumber, which is a wrapper for a kernel number of 8, 16, 32 or 64
OK, then at the very least we'll need something 64
have to
duplicate from the non-gerrit-supported git-hooks. Obviously, I'd rather
go with the one that's easier to maintain in gerrit.
Regards,
/Pete
From 9989b19894ac0e03a5e048e998aef340752f642f Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Thu, 10 May 2012 20:01:10 +0100
Subject
comparing with what's happening
in core or other backends, with a couple of warnings that should really
be usbi_warn().
Regards.
/Pete
From 67abd67778893631da0e822b57feef68cf9208e4 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Thu, 24 May 2012 11:42:47 +0100
Subject: [PATCH 2/2
On 2012.05.24 14:17, Xiaofan Chen wrote:
One git question first, how to revert the v2 patch and then apply
this patch?
If you just applied a patch, git reset HEAD should do the job... I
think (I'd have to look up the command, since with TGit I'm just doing
that in a couple of clicks by
On 2012.05.25 11:46, g...@novadsp.com wrote:
Sure, and there is an implementation, but the implementation needed
further work before being added into the Windows backend and the
author didn't work with Pete on that.
Note that the code pointed out by Peter is _NOT_ the one that is going
to be
On 2012.05.25 13:12, g...@novadsp.com wrote:
The libusb0 and libusbK drivers are signed and work fine on x64.
Yes. Might I ask how this all ties in (if at all) with Zadig? I have
been using this to great effect for firmware testing (thanks!).
Zadig was designed to help Windows users of the
On 2012.05.25 13:22, Ludovic Rousseau wrote:
The problem is when the flows are redirected to a file. The outputs
are buffered and no more ordered correctly between stdout and stderr.
Aha. I think I saw happen in the past and didn't realize this was the
actual cause.
A solution is to be able
On 2012.05.25 15:28, Yves Arrouye wrote:
ludovic.rouss...@gmail.com wrote:
I need a way to tell libusbx to use stdout (for every logs).
If all logs go to stderr, can't you just redirect stderr to stout
(e.g. 21 in a shell command)?
Before looking at introducing a way to use either of stderr
On 2012.05.28 11:53, Xiaofan Chen wrote:
Basically, xusb will try to access string descriptor 0xEE to find out if
the device is WCID and display the WCID data if that is the case (which
can be done on any platform, not just Windows). It looks like trying to
access 0xEE on Mac produces a pipe
On 2012.06.01 10:57, Ludovic Rousseau wrote:
Any progress on this patch?
I vote for its inclusion.
Now pushed. ;)
I also pushed another commit with more realignment of the OS-X logging
levels [1]. This is a follow up of the stalled pipe message we got with
xusb for the 0xEE string
/trac/libusbx/ticket/15
[2] http://www.libusb.org/ticket/110
[3]
http://libusb.6.n5.nabble.com/msvc-warning-in-libusb-h-about-zero-sized-array-td2730.html
From f688d97409e83fceb436c3d0025710bcd0b78c88 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Mon, 4 Jun 2012 01:13:51 +0100
On 2012.06.05 03:32, Xiaofan Chen wrote:
As per Pete, autoconf needs to be 2.50 minimum.
As per old libusb rather.
I don't mind making it later, if it's no more recent than 2009, but I
just don't know what value we should put there, and I don't see much
point to try to guess outside of
On 2012.06.13 12:46, Markus wrote:
Here's the log of the last good control transfer and the
consecutive one that's failing:
[ 3.130939] [15d8] libusbx: debug [windows_transfer_callback] handling
I/O completion with errcode 31
[ 3.130939] [15d8] libusbx: debug
also not forgetting about the xusb wording change for USB
LowSpeed, but I'm waiting to see if there's anything else we may want
to apply to xusb for 1.0.12.
Regards,
/Pete
From 8ea0ca3bf3acd7974535fa0713ddc14a0fe45f9c Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Wed, 13 Jun 2012
was used for an indication of success, Clang properly flagged it
as an issue.
Regards,
/Pete
From 21ce67310216dd1173a582b584399bf6096965ea Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Wed, 13 Jun 2012 13:33:00 +0100
Subject: [PATCH 1/2] Core: Fix Clang warnings
core.c:
* Result
The 2 Clang patches as well as the speed designation patch suggested by
Xiaofan have now been pushed to git.
As changes were applied to core, if you have an opportunity to test
before release, please do so. These warning fixes should be fairly safe,
but you never know...
Official v1.0.12
On 2012.06.14 15:43, Markus wrote:
when looking at the URBs, I don't
spot any difference except for the address.
(...)
I'm getting increasingly convinced that it's a device issue.
Looks that way.
If the values you get in the Control requests are the one you populated
in the app, there's not
On 2012.06.12 14:37, Xiaofan Chen wrote:
I think I have mentioned this before, the new VS11 Beta can
not convert the existing VS2010 project properly.
I don't have access to the 2011 beta, but given Microsoft's history with
Visual Studio, it's not surprising...
I think this
is not a real
Hi Markus,
On 2012.06.12 15:32, Markus wrote:
I'd like to replace a vendor tool for firmware download
to a developement board by using libusbx.
OK.
As of now, I can read and write memory by using vendor request
control transfers. According to the manufacturer this is the way
to go for
On 2012.06.13 19:19, Sean McBride wrote:
Have you looked at the HTML that scan-build generates?
Good point. Now that looked at it more closely, it is possible to fix
the issue at core.c:647 by switching a malloc to a calloc. What happens
there is that Clang sees a path where we may have a
On 2012.06.13 12:19, g...@novadsp.com wrote:
Does Zadig have its own list? Wondering about Zadig .INF files and
Nullsoft/Inno style installers.
Yes it does. See https://lists.sourceforge.net/lists/listinfo/libwdi-devel
It should also be OK to send Zadig/libwdi requests on this list if it
On 2012.06.15 19:56, Orin Eman wrote:
I compiled at warning level 4 with Visual Studio 2010. There is a lot
of noise...
Good point.
I don't think I recompiled at level 4 since last time we tried it in
libusb-devel, which was probably more than a year ago.
I have now added this item as
On 2012.06.15 11:06, Toby Gray wrote:
I'd be happy to submit a patch which made windows_set_configuration
return success with on bus activity but allowed an explicit
libusb_control_transfer for the same configuration to go onto the bus.
Would that be preferable?
As the handling of set
On 2012.06.17 14:00, Xiaofan Chen wrote:
In any case, the modification is benign and will work
with different version of dlltool, so I think it is good
to change libusb-1.0.def.
I'm still on the fence there.
I'd rather wait a few weeks and see if dlltool are going to fix this, as
there may
On 2012.06.18 15:37, Peter Stuge wrote:
Hotplug isn't there yet, and Liam's problem is because the Windows
backend doesn't currently implement what the libusb-1.0 API currently
offers. Without hotplug. This is a bug in the Windows backend.
After 2 similar issues, you still don't get it, so let
On 2012.06.18 16:31, Johannes Stezenbach wrote:
Doesn't Windows (WinUSB to be precise) return an error code
indicating the device was unplugged for the submitted transfers?
If Windows only returns unlugged status for one transfer
and forgets the other ones, can't you just fix this up in the
I created ticket #29 [1] to add your patch against the 1.0.13 milestone,
[1] https://sourceforge.net/apps/trac/libusbx/ticket/29
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
On 2012.06.18 18:38, Tim Roberts wrote:
philip.jos...@microchip.com wrote:
Just a note in regards to WinUSB and Windows 8. It would appear that a
device will not need to provide an INF as long as it provides Windows
specific info in its OS descriptors...
When we talked about this before, it
On 2012.06.18 20:31, Peter Stuge wrote:
What does GetLastError() return in the relevant cases after the
WinUsb functions return FALSE?
I'd expect [22] The device does not recognize the command.
In any case, if transfers have been submitted and are on the flying
list, and if timeouts are
On 2012.06.19 08:28, Peter Stuge wrote:
Pete Batard wrote:
the API is really only one part of it
In a library the API is almost the only thing that matters.
Ergo, you are stating that the resources a project can muster, and users
requests don't matter, as per the exact elements I
.
FWIW, Intel also have a warning level 5... you probably don't want to
see the whining that produces ;)
Not right now, no.
Regards,
/Pete
From 4ef3550cb8dac0ee1d46a4b9a6f165a1074de4d0 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Thu, 21 Jun 2012 20:17:09 +0100
Subject
On 2012.06.21 21:23, Sean McBride wrote:
It would be nice to have nightly builds of libusbx where the resulting
errors/warnings are gathered together for display.
I agree that it would be nice. However, since this is volunteer based,
I'm doubtful whether we can gather the minimal amount of
On 2012.06.24 01:22, Xiaofan Chen wrote:
Just found out that Fedora 17 ships with the defact dllwrap with
their MinGW-w64 based toolchain (32bit and 64bit) and I have the
exact same problem when cross-building libusbx under Fedora.
OK, then I don't think we have a choice. I just pushed your
On 2012.06.25 23:45, Pete Batard wrote:
- The only real controversial addon is that if (!dbg) UNUSED(dbg); in
libusb_init(), which is only there be OACR insists on wanting that
variable tested no matter what, before exiting the call. I thought about
somehow concealing this farce with a debug
On 2012.06.26 08:18, Ludovic Rousseau wrote:
I think it is a bad news to replace strncpy() by a for() loop just
because WDK's OACR doesn't like strncpy...
If you need a secure strncpy then strlcpy is there. But it is a BSD variant.
Yes, and there a strncpy_s on Windows, and probably other
On 2012.06.26 10:39, Timotei Dolean wrote:
It seems from the comments that WinUSB has some issues setting the
configuration?
Please see
http://sourceforge.net/apps/mediawiki/libusbx/index.php?title=Windows#Known_Restrictions:
WinUSB cannot be used to set a device configuration that is
On 2012.06.26 13:48, Timotei Dolean wrote:
Is there any way I (or someone) could be involved/help implememting the
other drivers (like libusb0.sys)? If yes, is there any information
regarding on what/how to contribute?
Well, time permitting, the implementation of libusb0.sys support should
On 2012.06.27 15:04, Chuck Cook wrote:
Aaaah yes, you are correct. Then this would indicate his device has no
configuration descriptors.
According to the error returned (LIBUSB_ERROR_NOT_FOUND) that seems to
be the case. This is the error the Windows backend returns if it was
unable to cache
On 2012.06.18 16:19, Sean McBride wrote:
On Sat, 16 Jun 2012 11:49:50 +0800, Xiaofan Chen said:
clang: warning: argument unused during compilation: '-std=gnu99'
The warning you see is telling you that you are specifying -std=gnu99 when
linking, which does nothing. gcc silently ignores that
On 2012.06.27 19:39, Ludovic Rousseau wrote:
Maybe the solution is to use -std=c99 instead.
If we use c99, then we have to revert to setting the -std option for
each individual toolchain, as we cannot use c99 on cygwin and MinGW for
some time. We used to do that at some stage, but we moved
On 2012.06.28 04:19, Jach Fong wrote:
On 27 Jun 2012 15:12:39 Pete Batard wrote:
According to the error returned (LIBUSB_ERROR_NOT_FOUND) that seems to
be the case. This is the error the Windows backend returns if it was
unable to cache a config descriptor durin enum.
Jach, if you're
Hi Rich,
On 2012.06.28 15:00, Xiaofan Chen wrote:
On Tue, Jun 26, 2012 at 4:52 AM, Rich von Lehe rhvonl...@gmail.com wrote:
In lieu of set_configuration in this case (there is only one config),
one process would claim_interface 0 and the other process would
claim_interface 1. I have a
On 2012.06.28 14:14, Xiaofan Chen wrote:
Enclosed please also find the zip of the html files.
Thanks! That helps a bit.
The two warnings in core are false positives that I think can be fixed
easily by having the following at line 686:
struct libusb_device **devs = NULL;
If you have a chance,
On 2012.06.29 10:14, Jach Fong wrote:
The xusb.exe in released 1.0.12 also have the same result.
I think the problem mostly was caused by my device. It is a device
I had built years ago using Silabs' F8051F320 and their Development tool
Version 2.2 with included HID example source.
Aha, so
On 2012.06.30 11:33, Xiaofan Chen wrote:
https://libusb.org/ticket/136
Not so sure if this is a real bug or not.
I'm hoping it won't be too difficult to confirm with a modified
xusb/plain sample that uses the OP's code, but only loops for 100 or
1000 iterations instead of indefinitely, and
On 2012.07.02 18:46, Chuck Cook wrote:
At the very bottom of Makefile.am :
dist-up: dist
rm -rf $(reldir)
mkdir -p $(reldir)
cp $(distdir).tar.bz2 $(reldir)
rsync -rv $(reldir)
frs.sourceforge.net:/home/frs/project/l/li/libusb/libusb-1.0/
rm -rf $(reldir)
On 2012.07.03 09:27, Tobias Powalowski wrote:
Now libusb-compat errors with this during compile:
core.c:35:6: error: nested redefinition of 'enum usbi_log_level'
core.c:35:6: error: redeclaration of 'enum usbi_log_level'
In file included from core.c:27:0:
This is a known issue.
Please apply
v2, that applies Hans' suggestion.
NB: This patch should be attached as inline
Regards,
/Pete
From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Mon, 2 Jul 2012 23:39:19 +0100
Subject: [PATCH] Core: Prefix LOG_LEVEL_ with LIBUSB_
On 2012.07.03 13:59, Xiaofan Chen wrote:
NB: This patch should be attached as inline
Actually it comes to me as both inline and attachment
Which is exactly what I want.
Pure inline is a PITA to work with, because everything's just text and
you never know if there's something of value in
Hi Sebastian,
On 2012.07.03 15:35, sebasti...@gmx-topmail.de wrote:
I encountered an issue using pcsc-lite and libusb on Ubuntu 10.04 LTS.
Now and then libusb segfaults and causes pcscd to crash.
The error occurred with libusb-1.0-0 (1.0.8), so I updated libusb-1.0-0 and
libusb-1.0-0-dev to
On 2012.07.03 14:38, Xiaofan Chen wrote:
I sent the patch both inline and as an attachment using Gmail.
Both are okay from what I see, no extra . But maybe you
will see the for the inline version. Did you see the for
my attachment?
Yup. This is how Thunderbird displays the inline version of
These wiki notifications are gonna be a major annoyance, so I'll see
what I can do to turn them off. However, github seriously limits both
what we can use as a source of notifications for new issues and how much
we can filter it, so this might be tricky...
Regards,
/Pete
On 2012.07.12 22:00, Hans de Goede wrote:
I believe that all arms / disarm should be done under the
flying transfer lock.
Same here. And my concern is that the disarm we do in
handle_timerfd_trigger() isn't.
Rather then reasoning ourselves a headache about how
it is absolutely safe in all
Hi Dave,
On 2012.07.13 00:08, Dave Camarillo wrote:
Hello, I was wondering what kinds testing has been done on Mac's with USB 3.0?
None on my end. I don't think any of the regulars here have had access
to a Mac with USB 3.0. Macs with 3.0 ports are fairly new and still
relatively uncommon,
On 2012.07.13 11:48, Xiaofan Chen wrote:
But then the
problem is that I am not 100% sure if you can get WHQL for a
class of USB device (no specific VID/PID). It seems to be a
reserved privilege of Microsoft.
Well, the Windows *Phone* division of Microsoft certainly took that
privilege to
1 - 100 of 478 matches
Mail list logo
