Finally got around looking further at the Darwin issue. It looks like
the main problem was that process_new_device() was maintaining a static
device pointer for the last device seen (last_dev), and the value wasn't
reset as it should when calling get_device_list(), resulting in a bad
pointer
On Thu, May 24, 2012 at 9:17 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, May 24, 2012 at 7:10 PM, Pete Batard p...@akeo.ie wrote:
Finally got around looking further at the Darwin issue. It looks like the
main
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 Tue, May 15, 2012 at 11:19 PM, Pete Batard p...@akeo.ie wrote:
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
On Mon, May 14, 2012 at 7:50 PM, Pete Batard p...@akeo.ie wrote:
v2, that takes into account what was discussed previously (but still
provides get_parent).
Obviously the two BSDs do not support this feature and I do not
see this is mentioned in your patch.
BTW, I have checked with Martin and
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. If
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 Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Somehow xusb now segfaults sometimes.
BTW, 1.0.11 release never segfaults.
mymacmini:examples xiaofanc$ ./xusb -d 04d8:fa2e
Using libusbx v1.0.11.10499
Opening device...
[timestamp] [threadID] facility level [function
On Mon, May 14, 2012 at 9:19 PM, Xiaofan Chen xiaof...@gmail.com wrote:
On Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Somehow xusb now segfaults sometimes.
BTW, 1.0.11 release never segfaults.
The default xusb is actually a wrapper. So I rebuild xusb with static
On Mon, May 14, 2012 at 7:50 PM, Pete Batard p...@akeo.ie wrote:
v2, that takes into account what was discussed previously (but still
provides get_parent).
Seems to work fine under Windows.
The difference between the first run and the 2nd run is that
I add an old full-speed USB Hub in between
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,
, resetting, getting
descriptors, attaching as a listener for plug/unplug notifications,
etc).
-Original Message-
From: Pete Batard [mailto:p...@akeo.ie]
Sent: Friday, May 11, 2012 11:46 AM
To: libusbx-devel@lists.sourceforge.net
Subject: Re: [Libusbx-devel] [PATCH] Add topology calls
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.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
Pete Batard wrote:
+int API_EXPORTED libusb_get_port_path(libusb_context *ctx, libusb_device
*dev, uint8_t* path, uint8_t path_len)
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
Pete Batard wrote:
Thus, as part of the overall topology, I have to very much disagree with
anyone who wants to pretend that providing a port number or hub location
has little use. ...
Finally, I'd like to remind everyone that we are purveyors of a generic
library. As long as we don't
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
than which USB port into which the device is plugged.
Thanks for keeping this under consideration.
-Original Message-
From: Pete Batard [mailto:p...@akeo.ie]
Sent: Friday, May 11, 2012 10:17 AM
To: libusbx-devel@lists.sourceforge.net
Subject: Re: [Libusbx-devel] [PATCH] Add topology calls
Pete Batard wrote:
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.
philip.jos...@microchip.com wrote:
Pete wrote:
an up to date device list, with all the USB properties
We currently do this in a layer above libusb
Can you tell us about how your users can use your layer? Ie. rough
details of the primitives and API offered?
Thanks!
//Peter
20 matches
Mail list logo
