libusb-win32-devel

[Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

Hello all,
I just took my newly formed USB code for Linux and tried it on Windows with
LibUsbWin32.

Everything seems to work fine, including the firmware upload and
usb_bulk_write, but usb_bulk_read returns -22.

Strangely i couldn't find a table of possible return error codes. Any idea ?

Thanks
-- 
Guillaume Dargaud
http://www.gdargaud.net/
  "I have a quantum car. Every time I look at the speedometer I get lost..."

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Guillaume Dargaud
> Sent: 2007 June 11 15:21
> To: lib...@li...
> Subject: [Libusb-win32-devel] Everything but usb_bulk_read works...
>=20
> Hello all,
> I just took my newly formed USB code for Linux and tried it=20
> on Windows with
> LibUsbWin32.
>=20
> Everything seems to work fine, including the firmware upload and
> usb_bulk_write, but usb_bulk_read returns -22.
>=20
> Strangely i couldn't find a table of possible return error=20
> codes. Any idea ?

Error 22 is an invalid parameter.  Input endpoint addresses
have to have the top bit set - this is incompatible with the
Linux version.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Adam K. <akr...@ro...>]

On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> > -----Original Message-----
> > From: lib...@li... 
> > [mailto:lib...@li...] On 
> > Behalf Of Guillaume Dargaud
> > Sent: 2007 June 11 15:21
> > To: lib...@li...
> > Subject: [Libusb-win32-devel] Everything but usb_bulk_read works...
> > 
> > Hello all,
> > I just took my newly formed USB code for Linux and tried it 
> > on Windows with
> > LibUsbWin32.
> > 
> > Everything seems to work fine, including the firmware upload and
> > usb_bulk_write, but usb_bulk_read returns -22.
> > 
> > Strangely i couldn't find a table of possible return error 
> > codes. Any idea ?
> 
> Error 22 is an invalid parameter.  Input endpoint addresses
> have to have the top bit set - this is incompatible with the
> Linux version.

It's not incompatible at all. Not setting that bit is a bug on any
platform. It just so happens that Linux lets you get away with it.

--Adam

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Adam Kropelin
> Sent: 2007 June 11 15:43
> To: lib...@li...
> Subject: Re: [Libusb-win32-devel] Everything but=20
> usb_bulk_read works...
>=20
> On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> >=20
> > Error 22 is an invalid parameter.  Input endpoint addresses
> > have to have the top bit set - this is incompatible with the
> > Linux version.
>=20
> It's not incompatible at all. Not setting that bit is a bug on any
> platform. It just so happens that Linux lets you get away with it.

It depends on your POV.  When you talk to somebody, do you refer to
endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
Linux has explicit code to set the top bit so that either is equally
valid.

My vote is that I prefer the Linux way.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Adam K. <akr...@ro...>]

On Mon, Jun 11, 2007 at 03:47:31PM +0100, Dave Higton wrote:
> > -----Original Message-----
> > From: lib...@li... 
> > [mailto:lib...@li...] On 
> > Behalf Of Adam Kropelin
> > Sent: 2007 June 11 15:43
> > To: lib...@li...
> > Subject: Re: [Libusb-win32-devel] Everything but 
> > usb_bulk_read works...
> > 
> > On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> > > 
> > > Error 22 is an invalid parameter.  Input endpoint addresses
> > > have to have the top bit set - this is incompatible with the
> > > Linux version.
> > 
> > It's not incompatible at all. Not setting that bit is a bug on any
> > platform. It just so happens that Linux lets you get away with it.
> 
> It depends on your POV.  When you talk to somebody, do you refer to
> endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
> Linux has explicit code to set the top bit so that either is equally
> valid.

There is an argument to made for the API to be forgiving; you're
performing a read, so obviously you must have meant to provide an input
endpoint address. Since you didn't, the library will fix it up for
you. That type of API makes me uncomfortable; I don't like an API that
thinks it knows more about what I want to do than me...but some 
people like to program that way. There's also an argument to be made 
for consistency; not every API call can easily do such a fixup for you. 
See usb_resetep(), for example. That one is even explicitly documented.

Personally I prefer consistency and exactness: Supply the actual
endpoint address, as specified in bEndpointAddress. Since we have to do
that for some API calls already, its best to do it for all of them.

--Adam

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Graeme G. <gr...@ar...>]

Adam Kropelin wrote:

> There is an argument to made for the API to be forgiving; you're
> performing a read, so obviously you must have meant to provide an input
> endpoint address. Since you didn't, the library will fix it up for
> you. That type of API makes me uncomfortable; I don't like an API that
> thinks it knows more about what I want to do than me...but some 
> people like to program that way. 

One solution (if there is a mechanism for it) would be for
the API to fix it up and issue a warning. Those who are
interested in clean code will note the warning and fix
the parameter, others can ignore it.

Another approach is to have "strict" and "forgiving" settings.
Default to "forgiving", and those interested in cleaning up their
code will turn on "strict".

Graeme Gill.

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

I may be new here, but what is the point of having two functions called 
usb_bulk_write and usb_bulk_read if you ALSO have to pass in them 
USB_DIR_OUT or USB_DIR_IN ?
Seems to defeat the purpose.
-- 
Guillaume Dargaud
http://www.gdargaud.net/
  "Error, no keyboard - press F1 to continue." 

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Guillaume Dargaud
> Sent: 2007 June 12 08:55
> To: lib...@li...
> Subject: Re: [Libusb-win32-devel] Everything but=20
> usb_bulk_read works...
>=20
> I may be new here, but what is the point of having two=20
> functions called=20
> usb_bulk_write and usb_bulk_read if you ALSO have to pass in them=20
> USB_DIR_OUT or USB_DIR_IN ?
> Seems to defeat the purpose.

Hey, this is Windoze.  It /has/ to be difficult.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Bertrik S. <be...@si...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Kropelin wrote:
> On Mon, Jun 11, 2007 at 03:47:31PM +0100, Dave Higton wrote:
>>> -----Original Message-----
>>> From: lib...@li... 
>>> [mailto:lib...@li...] On 
>>> Behalf Of Adam Kropelin
>>> Sent: 2007 June 11 15:43
>>> To: lib...@li...
>>> Subject: Re: [Libusb-win32-devel] Everything but 
>>> usb_bulk_read works...
>>>
>>> On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
>>>> Error 22 is an invalid parameter.  Input endpoint addresses
>>>> have to have the top bit set - this is incompatible with the
>>>> Linux version.
>>> It's not incompatible at all. Not setting that bit is a bug on any
>>> platform. It just so happens that Linux lets you get away with it.
>> It depends on your POV.  When you talk to somebody, do you refer to
>> endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
>> Linux has explicit code to set the top bit so that either is equally
>> valid.
> 
> There is an argument to made for the API to be forgiving; you're
> performing a read, so obviously you must have meant to provide an input
> endpoint address. Since you didn't, the library will fix it up for
> you. That type of API makes me uncomfortable; I don't like an API that
> thinks it knows more about what I want to do than me...but some 
> people like to program that way. There's also an argument to be made 
> for consistency; not every API call can easily do such a fixup for you. 
> See usb_resetep(), for example. That one is even explicitly documented.
> 
> Personally I prefer consistency and exactness: Supply the actual
> endpoint address, as specified in bEndpointAddress. Since we have to do
> that for some API calls already, its best to do it for all of them.

I agree completely.

The libusb API is not exact on what is meant with the 'ep' parameter.
The USB2.0 specification differentiates between an *endpoint number*
and an *endpoint address*, where the endpoint number is a simple 4-bit
number and the endpoint address is the endpoint number combined with
the direction bit.

USB2.0 specification suggests that it is possible for a device to
have both a 0x01 and 0x81 endpoint address (see for example paragraph
5.3.1.2: "Full-speed devices can have additional endpoints only limited
by the protocol definition (i.e., a maximum of 15 additional input
endpoints and 15 additional output endpoints).")
In that case, having libusb setting or clearing the top bit
would amount to converting the endpoint into a different and
possibly unrelated endpoint address, which is not acceptable.

IMO, the Linux implementation is wrong because it allows people to
be sloppy about this.

Regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbtyYETD6mlrWxPURAkD1AJ4qwJaQxIcOQ/xB7sa9rpeG4DmZ7wCgvMN0
Bf7kLCiO9cMY8bPJBlbjvZs=
=dh9I
-----END PGP SIGNATURE-----

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

>> > Error 22 is an invalid parameter.  Input endpoint addresses
>> > have to have the top bit set - this is incompatible with the
>> > Linux version.

That was it. Thanks guys.

BTW, in the process I discovered the undocumented functions usb_strerror() 
and usb_set_debug(255)
-- 
Guillaume Dargaud
http://www.gdargaud.net/