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
Pete wrote:
"It is clear that part of libusb(x) during enum aims at
duplicating what we would actually like the OS to provide us with, which
is an up to date device list, with all the USB properties libusb(x)
requires already filled, and preferably cached. If the OS doesn't, I
think we could us
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
On Thu, May 10, 2012 at 11:18 PM, Pete Batard wrote:
> I'm also planning to add the following content as "INSTALL_WIN.txt" in
> libusbx root, as the INSTALL content does not apply for some Windows
> environment. Not sending a patch as it's just a text file. If you have
> comments on it, let me kno
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
11 matches
Mail list logo
