Re: [Libusb-devel] [libusb] #6: Zero Length Packet issue

[libusb T. <tr...@li...>]

#6: Zero Length Packet issue
-------------------------+--------------------------------------------------
  Reporter:  nikias      |        Owner:     
      Type:  defect      |       Status:  new
 Component:  libusb-1.0  |   Resolution:     
  Keywords:  ZLP         |       Blocks:     
Blocked By:              |  
-------------------------+--------------------------------------------------
Changes (by www.google.com/accounts/o8/id?id=aitoawnx6bhsco20utb3w_lji0s4ph0xraz9pjy):

 * cc: chris2k01@… (added)


Comment:

 I'd like to point out my 2¢ here.

 I believe this flag should exist. As a ''user'' of libusb, I shouldn't
 need to know or care what an “URB” is. That string never appears in the
 USB 2.0 specification. All USB defines are packets, transactions (~3
 packets, token+data+handshake), and transfers (1 or more transactions).

 Various people have discussed above the quote from 5.7.3 that a transfer
 completes when the endpoint “Has transferred exactly the amount of data
 expected”, OR “Transfers a packet with a payload size less than
 ''wMaxPacketSize'' or transfers a zero-length packet”.

 The point is, the functions exposed by libusb are all defined in terms of
 ''transfers''. `libusb_submit_transfer`, `struct libusb_transfer`,
 `libusb_interrupt_transfer`, they all talk about transfers. To me, as a
 user, that means I ought not to have to mess around poking at
 configuration descriptors and such in my application and special-casing
 the ZLP case. This should all be handled for me. It's all part of a single
 transfer, after all. The only thing I should have to do is tell libusb
 whether my device is expecting the exact size of transfer I submitted
 (current behaviour) or whether the device is expecting a variable-sized
 transfer and hence needs proper termination (what would be provided with
 the special flag, noting that merely describing the flag as “adds a ZLP”
 is slightly misleading since it should really only do so if the transfer
 to which its attached is a multiple of max packet).

 So I vote in favour the transfer flag. It's been 17 months since the last
 comment; is there any word on when this will get into git (I checked out
 the tree and it looks like its not there despite some patches above)? For
 now I'll use the ugly workaround of manually checking the max packet size
 and adding a second transfer if necessary, but this feels like a huge
 break of abstraction.

-- 
Ticket URL: <http://libusb.org/ticket/6#comment:32>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace