On 2012.05.24 14:12, Xiaofan Chen wrote:
> I am not so sure if gerrit is good for libusbx or not. From the OpenOCD
> side it seems to be a success mostly. But it does prevent some users
> from posting patches as well. OpenOCD is considered to be a big
> project whereas libusb/libusbx are much small
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 acc
On Thu, May 24, 2012 at 9:17 PM, Xiaofan Chen wrote:
> On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote:
>> On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
>>> Finally got around looking further at the Darwin issue. It looks like the
>>> main problem was that process_new_device() was main
On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote:
> On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
>> 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
On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
> 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
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 re
On Tue, May 15, 2012 at 11:19 PM, Pete Batard 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
> un
On Mon, May 14, 2012 at 7:50 PM, Pete Batard 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 he does no
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
On 2012.05.15 00:54, Xiaofan Chen wrote:
> Nothing special to reproduce. You got 50% chance of segfaults running
> the same command again and again.
Yeah, I've actually been testing this, and I was able to reproduce it
against the benchmark device (haven't tested any other).
It seems all that's
On Mon, May 14, 2012 at 11:24 PM, Pete Batard wrote:
> On 2012.05.14 14:16, Xiaofan Chen wrote:
>> Somehow xusb now segfaults sometimes.
>
> It seems to segfault when retrieving the topological data on Mac, which
> of course explains why 1.0.11 is fine.
>
> [ 0.913785] [1307] libusbx: info [da
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 l
g, disconnecting, writing, reading, 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] [
On 2012.05.14 14:16, Xiaofan Chen wrote:
> The leading ">" in">From" 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
On Mon, May 14, 2012 at 7:50 PM, Pete Batard 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 the device
On Mon, May 14, 2012 at 9:19 PM, Xiaofan Chen wrote:
> On Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen 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
library and then run gdb. Here is th
On Mon, May 14, 2012 at 9:16 PM, Xiaofan Chen 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 call]
--
On Mon, May 14, 2012 at 7:50 PM, Pete Batard wrote:
> v2, that takes into account what was discussed previously (but still
> provides get_parent).
>
> >From 4ff57d754aed031b8b73e161e56064338b4bd06a Mon Sep 17 00:00:00 2001
One minor thing first.
The leading ">" in ">From" is automatically added b
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
Date: Mon, 14 May 2012 11:44:00 +0100
Subject: [PATCH] All: Add parent and port topology calls
*
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
On 2012.05.12 12:30, Ludovic Rousseau wrote:
> 2012/5/11 Pete Batard:
>
>> +/** \ingroup dev
>> + * Get the list of all port numbers from root for the specified device
>> + * \param dev a device
>> + * \param path the array that should contain the port numbers
>> + * \param path_len the maximum len
Pete Batard wrote:
> I'm puzzled as to why you're trying to blow such a minor API item
> out of proportion
Not at all out of proportion. The parameter is unneccessary and
redundant since the depth limit of 7 is in fact not arbitrary.
Every library should be convenient to use, and redundancy is not
2012/5/11 Pete Batard :
> +/** \ingroup dev
> + * Get the list of all port numbers from root for the specified device
> + * \param dev a device
> + * \param path the array that should contain the port numbers
> + * \param path_len the maximum length of the array
I propose to document that a "corr
On 2012.05.11 19:11, Peter Stuge wrote:
> philip.jos...@microchip.com wrote:
>> 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?
I'd also be curious about it.
On 2012.05.11 18:46, phili
On 2012.05.11 19:08, Peter Stuge wrote:
> This means taking some risks
> ..as opposed to erring on the side of caution
And you'll be free to take risks and live on the edge, for what is
really a minor detail not worth spending much time on, when/if you carry
the API in libusb. Your suggestion ha
On 2012.05.11 17:34, Tim Roberts wrote:
> "Every imaginable way." I hope you have some clue to the size of the
> can of worms you've opened up there.
Yes. It's called customer care, even if some may argue we don't have
"customers" as such.
As far as I'm concerned, "customers"/libusbx users are #
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
--
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 l
al numbers to differentiate devices
more 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: [
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
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
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 in
With the previous patches (and a little more as I found out the cygwin
thread ID setup was broken) having been pushed, let's get down to
something a bit more substantial.
Given the recent request, please find attached a proposal for the addon
of the following topology calls to the API:
* libu
33 matches
Mail list logo
