Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Ludovic Rousseau]

2012/9/6 Pete Batard :
> I also took the opportunity to update the copyright in our most public
> header, as we might as well promote libusbx there.

The goal of a copyright is not to promote something but to assign the
copyright to a legal entity.
libusbx.org has no legal existence and can not be assigned a copyright.

I agree it is a (very) good idea to mention http://libusbx.org in the
header, but not in the copyright section.
You can use something like:

" The libusbx project is hosted at http://libusbx.org "

PS: I am not a layer.

> ---
>  libusb/libusb.h   | 25 ++---
>  1 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/libusb/libusb.h b/libusb/libusb.h
> index de31a56..c41ea22 100644
> --- a/libusb/libusb.h
> +++ b/libusb/libusb.h
> @@ -1,7 +1,8 @@
>  /*
>   * Public libusbx header file
> - * Copyright © 2007-2008 Daniel Drake 
>   * Copyright © 2001 Johannes Erdfelt 
> + * Copyright © 2007-2008 Daniel Drake 
> + * Copyright © 2012 libusbx.org 
>   *
>   * This library is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU Lesser General Public


-- 
 Dr. Ludovic Rousseau

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] Gearing up for the libusbx v1.0.13 release

[Hans de Goede]

Hi,

On 09/06/2012 02:03 AM, Pete Batard wrote:
> Since we need to gear up for the 1.0.13 release

+1 For moving towards a 1.0.13 release.

> I have just pushed back
> a few of the tasks that we had planned but that I don't really see
> happening over the next few days, into 1.0.14. These include:
>
> - Adding the WinCE backend (Note to Toby: Yes, I've seen the update in
> your repo, and WinCE will be top of my list to integrate after 1.0.13.
> However, I had to make a choice between the FX2/FX3 sample and WinCE,
> and FX took the lead...)
> - The ever delayed gerrit+Jenkins (and creation of the 2.0 branch). I
> don't exactly like to delay those again, but if there's something that
> *can* be delayed without impacting our users, those fit the bill.
> - The USB 3.0 Endpoint Companion and BOS descriptors (unless I say
> "screw it", and go with adding the feature for Windows only, so that,
> filled with the guilt of trailing behind Windows, someone decides to
> provide at a Linux backend implementation at last).

I was not aware this needs any backend work, Linux gives you pretty
much raw descriptors access. So I thought this was just descriptor
parsing extensions. I must admit I've not looked into this at all,
due to lack of time. I hope to seriously start looking into libusb and
usb3 after October 15th. Planned things include adding support for
usb3 bulk streams to both the linux usbdevfs API and to libusb.

In the mean time if you're convinced that the libusb using application
part (so the external) API is solid, I'm fine with doing this for just
windows for now, we can always rework the internal API if necessary.

Regards,

Hans

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Hans de Goede]

Hi,

On 09/06/2012 04:35 AM, Orin Eman wrote:
> On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard  > wrote:
>
> This is #26: https://github.com/libusbx/__libusbx/issues/26 
> , but doesn't include BOS/EP 
> Companion.
>
> Note that the proposed patch fixes libusb_config_descriptor to use 
> bMaxPower, as it is labelled in the specs, rather than MaxPower => this can 
> break the compilation of existing applications.
>
> Now, the way I see it is:
> - Not many people use are likely to use the MaxPower attribute in their 
> apps
> - We're not breaking linking to the library
> - The few people who use MaxPower should easily be able to figure out why 
> they get a compilation error and fix it
> => I'd like to push for this change as I see it low impact, despite 
> affecting the API. But I'm ready to hear good arguments against the MaxPower 
> -> bMaxPower change.
>
> I also took the opportunity to update the copyright in our most public 
> header, as we might as well promote libusbx there.
>
>
>
>
> I don't think you should break existing code until libusbx 2.0.  I think you 
> should add:
>
> #define MaxPower bMaxPower

That was my initial thought to, but MaxPower is too generic of a name to define 
IMHO, I would
expect that to cause more problems then it fixes. As said few apps are expected 
to use
MaxPower, and fixing those who do is easy, and they will only break at 
compilation
time. So I'm with Pete here and suggest to just do the rename, with a clear 
warning about
it in the ChangeLog and NEWS files.

Regards,

Hans

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Hans de Goede]

Hi,

On 09/06/2012 09:16 AM, Ludovic Rousseau wrote:
> 2012/9/6 Pete Batard :
>> I also took the opportunity to update the copyright in our most public
>> header, as we might as well promote libusbx there.
>
> The goal of a copyright is not to promote something but to assign the
> copyright to a legal entity.
> libusbx.org has no legal existence and can not be assigned a copyright.
>
> I agree it is a (very) good idea to mention http://libusbx.org in the
> header, but not in the copyright section.
> You can use something like:
>
> " The libusbx project is hosted at http://libusbx.org";
>
> PS: I am not a layer.

+1

Regards,

Hans

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Toby Gray]

On 06/09/12 11:07, Hans de Goede wrote:
> Hi,
>
> On 09/06/2012 04:35 AM, Orin Eman wrote:
>> On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard > > wrote:
>>
>>  This is #26: https://github.com/libusbx/__libusbx/issues/26 
>> , but doesn't include BOS/EP 
>> Companion.
>>
>>  Note that the proposed patch fixes libusb_config_descriptor to use 
>> bMaxPower, as it is labelled in the specs, rather than MaxPower => this can 
>> break the compilation of existing applications.
>>
>>  Now, the way I see it is:
>>  - Not many people use are likely to use the MaxPower attribute in their 
>> apps
>>  - We're not breaking linking to the library
>>  - The few people who use MaxPower should easily be able to figure out 
>> why they get a compilation error and fix it
>>  => I'd like to push for this change as I see it low impact, despite 
>> affecting the API. But I'm ready to hear good arguments against the MaxPower 
>> -> bMaxPower change.
>>
>>  I also took the opportunity to update the copyright in our most public 
>> header, as we might as well promote libusbx there.
>>
>>
>>
>>
>> I don't think you should break existing code until libusbx 2.0.  I think you 
>> should add:
>>
>> #define MaxPower bMaxPower
> That was my initial thought to, but MaxPower is too generic of a name to 
> define IMHO, I would
> expect that to cause more problems then it fixes. As said few apps are 
> expected to use
> MaxPower, and fixing those who do is easy, and they will only break at 
> compilation
> time. So I'm with Pete here and suggest to just do the rename, with a clear 
> warning about
> it in the ChangeLog and NEWS files.

Would it be possible to add some sort of #define into libusb.h to 
determine what value to use?

For example the charging code in the 'Barry' project 
(http://repo.or.cz/w/barry.git/blob/HEAD:/tools/bcharge.cc#l182) would 
change from:

dev->config[0].MaxPower < 250

to

#ifdef LIBUSBX_USB_3_0_DESCRIPTOR_SUPPORT
   dev->config[0].bMaxPower < 250
#else
   dev->config[0].MaxPower < 250
#endif

The define to use could even just be based on on version number if that 
was available as a #define.

Without this it'd be necessary for any project wanting to query the 
MaxPower would have a set of limited choices:
1) Mandate that only libusbx version >= 1.0.x and not libusb is supported
2) Mandate that only libusb and not libusbx is supported
3) Add configure tests for if libusb, libusbx < 1.0.x or libusbx >= 
1.0.x is around (which isn't possible for projects which don't use 
configure, such as Visual Studios based Windows projects)

None of which are seem very desirable (to the people who develop the 
projects using the library). It's a shame that C doesn't support 
anonymous unions like C++.

Regards,

Toby

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] Gearing up for the libusbx v1.0.13 release

[Toby Gray]

On 06/09/12 01:03, Pete Batard wrote:
> Since we need to gear up for the 1.0.13 release, I have just pushed 
> back a few of the tasks that we had planned but that I don't really 
> see happening over the next few days, into 1.0.14. These include:
>
> - Adding the WinCE backend (Note to Toby: Yes, I've seen the update in 
> your repo, and WinCE will be top of my list to integrate after 1.0.13. 
> However, I had to make a choice between the FX2/FX3 sample and WinCE, 
> and FX took the lead...)

That fine. I apologise for not managing to find time to work through all 
of your review comments.

I think it makes sense to get 1.0.13 out without WinCE support rather 
than rushing the merging of poll_wince.c and poll_windows.c and not 
being able to test it properly on either desktop Windows or WinCE.

Regards,

Toby

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline

[Xiaofan Chen]

On Tue, Sep 4, 2012 at 6:45 AM, Pete Batard  wrote:
> Just an update. I now have a partial patch for composite support, that
> appears to works fine with WinUSB and libusbK, but still doesn't
> properly set the interfaces for libusb0.

Just checked the latest git and it indeed solved the problems
I have with the USB Composite Device (FT2232H based
Jtag debugger).



-- 
Xiaofan

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline

[Xiaofan Chen]

On Thu, Sep 6, 2012 at 6:26 AM, Pete Batard  wrote:
> OK, IMO, the best way to address that last issue we have with libusb0 as
> composite device is by modifying the libusb0 inf file to create a Device
> Interface GUID during installation.
>
> In this case, this is really a one liner change in libwdi:
> --- "a/D:\\libwdi\\libwdi\\libusb0.inf.in"
> +++ "b/D:\\libwdi\\libwdi\\libusb0.inf.in"
>   [libusb_add_reg_hw]
>   HKR,,SurpriseRemovalOK,0x00010001,1
> +HKR,,DeviceInterfaceGUIDs,0x0001,%DeviceGUID%

Yes this indeed solved the problem with libusb0.sys
with regard to composite device.
>
> And now for some additional notes:
>
> Note 1: Unlike what is the case for the Class GUID, libwdi creates the
> Device Interface GUID on the fly (kind of makes sense if you want the
> interface GUID to be unique)
>
> Note 2: As long as you use the default composite parent Windows driver,
> you can very much access composite interface #2 with libusbx even if
> interface #1 has no driver, or a proprietary/non libusbx compatible one.
> It's only when WinUSB is in charge of the parent composite device that
> you have to claim #1 before you can claim #2.

It is good to be put in the doc.

> Note 3: Not having a Device Interface GUID is only an issue for
> composite devices. For anything that's not composite, it doesn't matter
> if the inf has one or not. I'll try to add a note about this in the
> Windows backend limitations.

It is also good to put this in the doc.



-- 
Xiaofan

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline

[Xiaofan Chen]

On Thu, Sep 6, 2012 at 9:56 PM, Xiaofan Chen  wrote:
> On Thu, Sep 6, 2012 at 6:26 AM, Pete Batard  wrote:
>> OK, IMO, the best way to address that last issue we have with libusb0 as
>> composite device is by modifying the libusb0 inf file to create a Device
>> Interface GUID during installation.
>>
>> In this case, this is really a one liner change in libwdi:
>> --- "a/D:\\libwdi\\libwdi\\libusb0.inf.in"
>> +++ "b/D:\\libwdi\\libwdi\\libusb0.inf.in"
>>   [libusb_add_reg_hw]
>>   HKR,,SurpriseRemovalOK,0x00010001,1
>> +HKR,,DeviceInterfaceGUIDs,0x0001,%DeviceGUID%
>
> Yes this indeed solved the problem with libusb0.sys
> with regard to composite device.

Since you have not released the update Zadig yet. I
manually edited the inf file generated by libusbK's
inf-wizard2 (MSVC based) and installed the driver.

I have not tested the filter cases since it will rely
on an updated Zadig or the libusb-win32 install-filter.exe.


-- 
Xiaofan

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

[Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN

[Chris McClelland]

OK, I made more progress with my Windows/Linux discrepancies, and I have
now hit another problem. I haven't totally ruled out the possibility
that it's another FX2 firmware bug, but I have narrowed it down to a
pretty simple example on the host and FX2 side:

http://www.swaton.ukfsn.org/temp/libusbx.tar.gz

Basically, the supplied FX2 firmware (in libusbx/fx2/fw/firmware.hex)
enumerates with two IN endpoints, EP1IN and EP2IN. It also supports a
couple of OUT vendor commands, 0x81 and 0x82. Both ignore wValue and
wIndex. Both accept some OUT data on EP0. Data written to command 0x81
is put in the EP1IN buffer ready for the host to read it back.
Similarly, data written to command 0x82 is put in the EP2IN buffer ready
for the host to read it back.

On the host side there's a small libusbx-based test program
(libusbx/host/test/test.c), which accepts a command-line argument of "1"
or "2". If "1", it writes 16 bytes of data to vendor command 0x81 and
then tries to read it back from EP1IN. Similarly, if "2", it writes the
16 bytes to vendor command 0x82 and then tries to read it back from
EP2IN.

On Linux, both EP1IN and EP2IN read back correctly.

On Windows, regardless of whether I use the winusb, libusbk or libusb0
drivers, the behaviour is the same: the EP2IN readback works fine, but
the EP1IN readback returns immediately with zero bytes.

I have included the debug log and a USB trace for each of the four
configurations (linux, winusb, libusbk & libusb0) in the archive; each
has the EP2IN readback attempt first, then the EP1IN attempt.

I thought about implementing the same protocol in an Atmel AVR, to
eliminate the possibility that it's just more FX2 weirdness, but I
thought I'd post in the current state in case anyone has ideas.

The libusbx code included in the archive is the github head as of a
couple of days ago. I'm happy to try with the latest head if necessary.

Chris



--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN

[Tim Roberts]

Chris McClelland wrote:
> Basically, the supplied FX2 firmware (in libusbx/fx2/fw/firmware.hex)
> enumerates with two IN endpoints, EP1IN and EP2IN.

Endpoint 1 is the poor stepchild in the FX2.  The functionality is
limited, the buffering is fixed and limited, and it uses different
registers from the other endpoints.  As a general rule, you'll be much
happier if you forget about it, and always restrict yourself to the
even-numbered endpoints.

Your descriptors have the max packet size set to 64 for endpoint 1. 
That's not valid.  In a high-speed devices, bulk endpoints must ALWAYS
have a max packet size of 512.  That's required by the spec.  Because
the FX2 only has a 64-byte buffer for endpoint 1, that presents a
philosophical problem, and the FX2 data sheet points this out.  You have
to report it as 512 bytes, but make sure you never try to do a packet
larger than 64.

-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.


--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN

[Chris McClelland]

You sir are a genius.

Changing the descriptors to report 512 bytes fixes the problem.

I'm aware of the limitations of EP1, but happy with it nevertheless. I
basically have a pair of very fast data channels (EP2OUT & EP6IN) for
exchanging data with an FPGA, and a pair of much slower channels (EP1OUT
& EP1IN) for JTAG.

The EP2&6 pair seems to require quad-buffering in order to get the best
throughput (I measure 43MiB/s when quad-buffered and about 33MiB/s when
double-buffered), which uses up all the 2KiB FIFO buffer space, leaving
only the 64 bytes for each of EP1OUT, EP1IN & EP0.

Since the JTAG streams are limited by the speed of the 8051, keeping the
send/receive chunks down to 64 bytes is perfectly fine, and possible
because I control the code on both sides.

The crucial piece of the puzzle which I was missing was the fact that
even though the "application" code on both ends of the link agrees to
use packets of 64 bytes or fewer, the "system" code in between needs to
see the EP1IN size reported as 512 bytes.

Thanks again!

Chris


On Thu, 2012-09-06 at 09:55 -0700, Tim Roberts wrote:
> Chris McClelland wrote:
> > Basically, the supplied FX2 firmware (in libusbx/fx2/fw/firmware.hex)
> > enumerates with two IN endpoints, EP1IN and EP2IN.
> 
> Endpoint 1 is the poor stepchild in the FX2.  The functionality is
> limited, the buffering is fixed and limited, and it uses different
> registers from the other endpoints.  As a general rule, you'll be much
> happier if you forget about it, and always restrict yourself to the
> even-numbered endpoints.
> 
> Your descriptors have the max packet size set to 64 for endpoint 1. 
> That's not valid.  In a high-speed devices, bulk endpoints must ALWAYS
> have a max packet size of 512.  That's required by the spec.  Because
> the FX2 only has a 64-byte buffer for endpoint 1, that presents a
> philosophical problem, and the FX2 data sheet points this out.  You have
> to report it as 512 bytes, but make sure you never try to do a packet
> larger than 64.
> 



--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN

[Tim Roberts]

Chris McClelland wrote:
> The EP2&6 pair seems to require quad-buffering in order to get the best
> throughput (I measure 43MiB/s when quad-buffered and about 33MiB/s when
> double-buffered),...

Yes.  You should also be aware that those speeds are highly dependent on
the quality of the host controller, and the other devices on the bus. 
We, also, have sustained 45 MB/s through an FX2 bulk pipe, but only on
certain host controllers.  The same hardware in another machine won't
push beyond about 30 MB/s.

And bulk transfers, of course, are last priority, and compete for
bandwidth equally amongst themselves.  If you have a USB keyboard or
mouse or speakers or camera, all of those get their pieces first.

As long as your buffering can handle that, you're fine, but it's
dangerous to make assumptions about bulk throughput...


> Since the JTAG streams are limited by the speed of the 8051, keeping the
> send/receive chunks down to 64 bytes is perfectly fine, and possible
> because I control the code on both sides.

Yes.  It is easy to forget how abysmally slow the FX2's 8051 is.  At
best, you get 3 MIPS.

-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.


--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Orin Eman]

On Thu, Sep 6, 2012 at 3:07 AM, Hans de Goede  wrote:

> Hi,
>
> On 09/06/2012 04:35 AM, Orin Eman wrote:
>
>> On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard > p...@akeo.ie>> wrote:
>>
>> This is #26: 
>> https://github.com/libusbx/__**libusbx/issues/26<
>> https://github.com/libusbx/**libusbx/issues/26>,
>> but doesn't include BOS/EP Companion.
>>
>>
>> Note that the proposed patch fixes libusb_config_descriptor to use
>> bMaxPower, as it is labelled in the specs, rather than MaxPower => this can
>> break the compilation of existing applications.
>>
>> Now, the way I see it is:
>> - Not many people use are likely to use the MaxPower attribute in
>> their apps
>> - We're not breaking linking to the library
>> - The few people who use MaxPower should easily be able to figure out
>> why they get a compilation error and fix it
>> => I'd like to push for this change as I see it low impact, despite
>> affecting the API. But I'm ready to hear good arguments against the
>> MaxPower -> bMaxPower change.
>>
>> I also took the opportunity to update the copyright in our most
>> public header, as we might as well promote libusbx there.
>>
>>
>>
>>
>> I don't think you should break existing code until libusbx 2.0.  I think
>> you should add:
>>
>> #define MaxPower bMaxPower
>>
>
> That was my initial thought to, but MaxPower is too generic of a name to
> define IMHO, I would
> expect that to cause more problems then it fixes. As said few apps are
> expected to use
> MaxPower, and fixing those who do is easy, and they will only break at
> compilation
> time. So I'm with Pete here and suggest to just do the rename, with a
> clear warning about
> it in the ChangeLog and NEWS files.
>


Yes the problem is easy to fix - for programmers, but not all that update
and build packages are.

A preferable (to me) alternative would be an anonymous union, but I was
unsure that all compilers would accept it.

Orin.
--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Hans de Goede]

Hi,

On 09/06/2012 08:20 PM, Orin Eman wrote:
>
> On Thu, Sep 6, 2012 at 3:07 AM, Hans de Goede  > wrote:
>
> Hi,
>
> On 09/06/2012 04:35 AM, Orin Eman wrote:
>
> On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard   >> wrote:
>
>  This is #26: https://github.com/libusbx/libusbx/issues/26 
>  
>  >, but doesn't include BOS/EP 
> Companion.
>
>
>  Note that the proposed patch fixes libusb_config_descriptor to 
> use bMaxPower, as it is labelled in the specs, rather than MaxPower => this 
> can break the compilation of existing applications.
>
>  Now, the way I see it is:
>  - Not many people use are likely to use the MaxPower attribute 
> in their apps
>  - We're not breaking linking to the library
>  - The few people who use MaxPower should easily be able to 
> figure out why they get a compilation error and fix it
>  => I'd like to push for this change as I see it low impact, 
> despite affecting the API. But I'm ready to hear good arguments against the 
> MaxPower -> bMaxPower change.
>
>  I also took the opportunity to update the copyright in our most 
> public header, as we might as well promote libusbx there.
>
>
>
>
> I don't think you should break existing code until libusbx 2.0.  I 
> think you should add:
>
> #define MaxPower bMaxPower
>
>
> That was my initial thought to, but MaxPower is too generic of a name to 
> define IMHO, I would
> expect that to cause more problems then it fixes. As said few apps are 
> expected to use
> MaxPower, and fixing those who do is easy, and they will only break at 
> compilation
> time. So I'm with Pete here and suggest to just do the rename, with a 
> clear warning about
> it in the ChangeLog and NEWS files.
>
>
>
> Yes the problem is easy to fix - for programmers, but not all that update and 
> build packages are.
>
> A preferable (to me) alternative would be an anonymous union, but I was 
> unsure that all compilers would accept it.

An anonymous union would work for me, but I'm not sure all the compilers we 
want to support support
this, esp. the windows ones may not... Pete ?

Regards,

Hans

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Orin Eman]

On Thu, Sep 6, 2012 at 11:28 AM, Hans de Goede  wrote:





> >
> >
> > I don't think you should break existing code until libusbx 2.0.
>  I think you should add:
> >
> > #define MaxPower bMaxPower
> >
> >
> > That was my initial thought to, but MaxPower is too generic of a
> name to define IMHO, I would
> > expect that to cause more problems then it fixes. As said few apps
> are expected to use
> > MaxPower, and fixing those who do is easy, and they will only break
> at compilation
> > time. So I'm with Pete here and suggest to just do the rename, with
> a clear warning about
> > it in the ChangeLog and NEWS files.
> >
> >
> >
> > Yes the problem is easy to fix - for programmers, but not all that
> update and build packages are.
> >
> > A preferable (to me) alternative would be an anonymous union, but I was
> unsure that all compilers would accept it.
>
>
> An anonymous union would work for me, but I'm not sure all the compilers
> we want to support support
> this, esp. the windows ones may not... Pete ?
>


I checked both VC6 and 2010 Express and they were both OK.

Orin.
--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] More Windows/Linux discrepancies: reading from EP1IN

[Chris McClelland]

> As long as your buffering can handle that, you're fine, but it's
> dangerous to make assumptions about bulk throughput...
> 
Understood. It's my job as library designer to ensure I do everything I
can to ensure performance is optimal assuming ideal conditions (i.e if
there is slowness anywhere, it's not *my* fault).


> Yes.  It is easy to forget how abysmally slow the FX2's 8051 is.  At
> best, you get 3 MIPS.
> 
It's slow, but not *that* slow. Each bus cycle is four 48MHz clocks,
giving 12 million bus cycles per second. Most instructions take one or
two bus cycles, with branching taking three or four. My guess would be
something around 5-8 MIPS.


--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs

[Pete Batard]

On 2012.09.06 19:51, Orin Eman wrote:
> On Thu, Sep 6, 2012 at 11:28 AM, Hans de Goede   > A preferable (to me) alternative would be an anonymous union, but
> I was unsure that all compilers would accept it.
>
>
> An anonymous union would work for me

That's ugly and IMO that's pretty much stating "even obvious mistakes 
are OK to leave in".

Therefore I don't agree with that approach. If you are serious about 
following the specs, then you shouldn't keep obvious erroneous 
deviations from the specs. Instead, you should address them.

Libusb and libusbx made the decision to follow the USB specs, up to the 
designations of the various attributes that we publicize in the header. 
And the real problem is someone screwed up when they wrote the libusb 
header: They should have used bMaxPower (this is not a new USB 3.0 
designation - bMaxPower is what's in the 2.0 specs, and I haven't 
checked 1.0), but they didn't. So that's what we *fix*.

And yeah, because we're dealing with a library that can be shared, it's 
going to be an annoyance, but you're always gonna end up annoyed when 
someone fixes a mess. We screwed up, and we're sorry, but to be credible 
with regards to our effort, we also need to stick to the specs. And just 
like specs come with errata that specs users are supposed to follow, and 
that may very much contradict earlier data, we should be able to produce 
our own erratas through fixes. I.e. "We told you to use MaxPower, but 
that was a typo. If you care about the USB specs as much as we do, then 
you should switch to using bMaxPower and ensure that the library you 
link against also uses bMaxPower. We're very sorry, but shit and 
breakage happen, that need to be fixed."

Thus, if people using MaxPower feel strongly enough about not having to 
modify their software/tell their users that they'll need to ensure they 
use 1.0.13 or later with the (hopefully) handful of applications that 
use MaxPower, my advice will be to link statically for a while.

Now, if there's a majority vote to have the anonymous union, I'll go 
with the majority (but then I'll ask you to submit a patch proposal on 
top of the v2 for copyright that I'm going to post shortly, especially 
if you want me to check that it works for Windows before release). But I 
think that's a poor decision, and I'll always have second thoughts about 
established apps that have no flexibility whatsoever to handle errata: 
We're not trying to break the API because we like it. Instead, we're 
very much fixing an API that was broken. And, once again, keeping the 
correct along with the incorrect doesn't seem like the proper way to go 
for me.

Besides, I'm ready to bet that there aren't gonna be that many people 
that are going to be inconvenienced by this, and if we keep MaxPower as 
fair game, we're likely to get a lot more people annoyed when we 
eventually remove it.

Alternatively, we also can bump the next version to 1.1.1, because of 
the API breakage, and declare the 1.0 API incompatible with 1.1, which 
is what we'd do if we went with the proposal of waiting for 2.0 to 
introduce that fix.

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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [PATCH] Update libusb.h header in accordance with USB 3.0 specs v2

[Pete Batard]

v2. To keep it short, besides a link to libusbx.org, I very much want to 
have a 2012 year mentioned in there, to show that we're actively 
updating the library. That's why I tried to combine the whole thing in 
the copyright line. So, from now on, you're gonna have my name there.


Regards,

/Pete
>From e06b48761b644be977f1d6c745f2ff0d93e72cc6 Mon Sep 17 00:00:00 2001
From: Pete Batard 
Date: Thu, 6 Sep 2012 00:47:08 +0100
Subject: [PATCH] Core: Update libusb.h header in accordance with USB 3.0
 specs

* Also update copyright notice
---
 libusb/libusb.h   | 26 +++---
 libusb/version_nano.h |  2 +-
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/libusb/libusb.h b/libusb/libusb.h
index de31a56..ae00c53 100644
--- a/libusb/libusb.h
+++ b/libusb/libusb.h
@@ -1,7 +1,9 @@
 /*
  * Public libusbx header file
- * Copyright © 2007-2008 Daniel Drake 
  * Copyright © 2001 Johannes Erdfelt 
+ * Copyright © 2007-2008 Daniel Drake 
+ * Copyright © 2012 Pete Batard 
+ * For more information, please visit: http://libusbx.org
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -231,6 +233,9 @@ enum libusb_descriptor_type {
 
/** Hub descriptor */
LIBUSB_DT_HUB = 0x29,
+
+   /** SuperSpeed Hub descriptor */
+   LIBUSB_DT_SUPERSPEED_HUB = 0x2A,
 };
 
 /* Descriptor sizes per descriptor type */
@@ -277,7 +282,7 @@ enum libusb_transfer_type {
 };
 
 /** \ingroup misc
- * Standard requests, as defined in table 9-3 of the USB2 specifications */
+ * Standard requests, as defined in table 9-5 of the USB 3.0 specifications */
 enum libusb_standard_request {
/** Request status of the specific recipient */
LIBUSB_REQUEST_GET_STATUS = 0x00,
@@ -315,6 +320,13 @@ enum libusb_standard_request {
 
/** Set then report an endpoint's synchronization frame */
LIBUSB_REQUEST_SYNCH_FRAME = 0x0C,
+
+   /** Sets both the U1 and U2 Exit Latency */
+   LIBUSB_REQUEST_SET_SEL = 0x30,
+
+   /** Delay from the time a host transmits a packet to the time it is
+ * received by the device. */
+   LIBUSB_SET_ISOCH_DELAY = 0x31,
 };
 
 /** \ingroup misc
@@ -394,7 +406,7 @@ enum libusb_iso_usage_type {
 
 /** \ingroup desc
  * A structure representing the standard USB device descriptor. This
- * descriptor is documented in section 9.6.1 of the USB 2.0 specification.
+ * descriptor is documented in section 9.6.1 of the USB 3.0 specification.
  * All multiple-byte fields are represented in host-endian format.
  */
 struct libusb_device_descriptor {
@@ -448,7 +460,7 @@ struct libusb_device_descriptor {
 
 /** \ingroup desc
  * A structure representing the standard USB endpoint descriptor. This
- * descriptor is documented in section 9.6.3 of the USB 2.0 specification.
+ * descriptor is documented in section 9.6.6 of the USB 3.0 specification.
  * All multiple-byte fields are represented in host-endian format.
  */
 struct libusb_endpoint_descriptor {
@@ -498,7 +510,7 @@ struct libusb_endpoint_descriptor {
 
 /** \ingroup desc
  * A structure representing the standard USB interface descriptor. This
- * descriptor is documented in section 9.6.5 of the USB 2.0 specification.
+ * descriptor is documented in section 9.6.5 of the USB 3.0 specification.
  * All multiple-byte fields are represented in host-endian format.
  */
 struct libusb_interface_descriptor {
@@ -560,7 +572,7 @@ struct libusb_interface {
 
 /** \ingroup desc
  * A structure representing the standard USB configuration descriptor. This
- * descriptor is documented in section 9.6.3 of the USB 2.0 specification.
+ * descriptor is documented in section 9.6.3 of the USB 3.0 specification.
  * All multiple-byte fields are represented in host-endian format.
  */
 struct libusb_config_descriptor {
@@ -590,7 +602,7 @@ struct libusb_config_descriptor {
/** Maximum power consumption of the USB device from this bus in this
 * configuration when the device is fully opreation. Expressed in units
 * of 2 mA. */
-   uint8_t  MaxPower;
+   uint8_t  bMaxPower;
 
/** Array of interfaces supported by this configuration. The length of
 * this array is determined by the bNumInterfaces field. */
-- 
1.7.11.msysgit.0

--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] libusb-win32 and libusbK support has now been pushed to mainline

[Pete Batard]

On 2012.09.06 15:02, Xiaofan Chen wrote:
> Since you have not released the update Zadig yet.

Well, I said 24 hours, which, due to various circumstances, I very much 
meant. But now Zadig v2.0.1.158 has been released...

Not sure when I'll release libwdi, as there's one last issue that I'd 
like to address.

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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] Gearing up for the libusbx v1.0.13 release

[Pete Batard]

On 2012.09.06 11:04, Hans de Goede wrote:
> In the mean time if you're convinced that the libusb using application
> part (so the external) API is solid, I'm fine with doing this for just
> windows for now

I'm never convinced that anything I code is solid. Ever.
That's why I subscribe to RERO. :)
It's only when others start to use your code that you get hints about 
how solid it really is...

I guess proposing the API+Windows patch for inclusion will depend on how 
much other stuff we have to deal with before RC. If it's likely we can 
use the extra breathing space, I'll delay it for 1.0.14, especially if 
you say you may have some room to look into it past mid October. 
Besides, I'm really not that hell bent on introducing API breakage, when 
there's a possibility Linux could require API adjustments.

I'll also point to my previous post that highlighted a few things we 
might want to look into with regards to BOS/EP Comp:
https://sourceforge.net/mailarchive/forum.php?thread_name=4FCCA5E3.8080101%40akeo.ie&forum_name=libusbx-devel

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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

[Libusbx-devel] question on libusb_bulk_transfer and libusb_fill_bulk_transfer

[John Chen]

Hi,

The device I am working right now demanding sending and receiving data in
unsigned int, and every bit has to be in exact position, in windows it is
easy as the DeviceIoContorl takes a void pointer, but in libusb, both
libusb_bulk_transfer and libusb_fill_bulk_transfer only takes unsigned
char*.

when writing, I am combine all the unsigned int into string,
(no sure if this will work or not) but when reading, there could be so many
different combinations, e.g. if libusb returns the following:
125
126
210

how do I know how to pack the data into unsigned int and how many unsigned
int?


 any advice?
Thanks.
John
--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] question on libusb_bulk_transfer and libusb_fill_bulk_transfer

[David Grant]

On Thu, Sep 6, 2012 at 5:22 PM, John Chen  wrote:

> Hi,
>
> The device I am working right now demanding sending and receiving data in
> unsigned int, and every bit has to be in exact position, in windows it is
> easy as the DeviceIoContorl takes a void pointer, but in libusb, both
> libusb_bulk_transfer and libusb_fill_bulk_transfer only takes unsigned
> char*.
>
> when writing, I am combine all the unsigned int into string char>, (no sure if this will work or not) but when reading, there could be
> so many different combinations, e.g. if libusb returns the following:
> 125
> 126
> 210
>
> how do I know how to pack the data into unsigned int and how many unsigned
> int?
>
>
You can't do "string". The string class is not a template,
it is an instantiation of basic_string defined as "typedef
basic_string string". So you could do "basic_string".
 But I'm not sure why you would want to. You are not working with "strings"
here, it sounds like you are working with integers. Why don't you just
allocate enough memory (get a void*) and copy your ints to the memory
location pointed to by the void*, then cast the void * to an unsigned * and
pass it to libusb_bulk_transfer. The length parameter would be (number of
ints you have)*(sizeof(unsigned int)/sizeof(unsigned char)).

Dave
--
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 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel