[Libusbx-devel] libusb.org tickets discussion

[Hans de Goede]

Hi,

On 04/14/2012 08:02 AM, Xiaofan Chen wrote:
> http://www.libusb.org/report/12?sort=type&asc=1&page=1
>
> Ticket	 Summary	 Type	 Owner	 Status	 Created
> ++++++++
> #2	ISO C++ forbids zero-size array 'iso_packet_desc'	
> defect		new	07/31/09
>
> Safe to ignore for now?

Yes / +1

> ++++++++
>
> #3	libusb:error [__open_sysfs_attr], errno=2	
> defect               new	07/31/09
>
> No details from the original poster and not so sure about if it
> is relevant any more.

I've actually seen this myself recently, this happens when we hit
a race where a device goes away while we're enumerating it. We should
change the code to catch errno==ENOENT and assume ENODEV in that case
(and thus not complain).

> ++++++++
>
> #6	Zero Length Packet issue	
> defect		new	08/20/09
>
> Is it really necessary to replicate this to other OS? Probably
> nice to copy the ticket to libusbx.

Lets duplicate this one, I think Peter has recently done some work
on this, but we want to make sure we get this right, I know from
experience that sometimes it is useful to get told about
0 sized isoc packets , so this is a real issue.

> ++++++++
>
> #77	get_max_packet_size returns bad value when alternative interface is used	
> defect		new	12/08/10
>
> Not worth fixing?

The problem is we cannot fix this without breaking API/ABI.
Note that we already have 2 max packet size functions:

libusb_get_max_packet_size()
libusb_get_max_iso_packet_size()

Where libusb_get_max_iso_packet_size() fixes what really is a bug in
libusb_get_max_packet_size(), the problem with the second one is that it
does not take the alt-setting into account, which is really stupid since
for isoc endpoints the max packet size for alt 0 (which it will most likely
return) is always 0. So in essence libusb_get_max_iso_packet_size() is
completely broken ...

So at a minimum we should fix the docs to explain how broken both of these
are. Ideally we should add a 3th one so that we can say in the docs to
just use the 3th one ...

> +++++++
>
> #80	Lose a packet when there is null packet in an isochronous transfer
> (libusb-1.0.8, linux 2.6.18)	
>
> defect	pvergain	new	12/14/10
>
> No details from the original poster and not so sure about if it is
> relevant any more.

As I already mentioned in the bug report I've audited all relevant code
paths and I cannot find any issues. Also I've not hit this myself while
I've been testing libusb with tons of isoc devices (through usb
redirection). So I say lets not copy this one.

> ++++++++
>
> #88	Crash during cancellation of transfer when device disconnected	
> defect	hjelmn	accepted	01/18/11
>
> Good to copy the ticket to libusbx.

+1

> +++++++++
>
> #101	Income data is lost after a timeout reading from libusb_interrupt_transfer	
> defect		new	02/24/11
>
> No details from the original poster and not so sure about if it is
> relevant any more.

This is a weird one, esp. since in general you should not set a timeout
on interrupt transfers, ie who knows when the user will next move the mouse /
press a key, it may be seconds, but it also may be hours ...

I vote for not copying this one.

> +++++++++
> #123	libusb_handle_events_timeout() only handles one event	
> defect		new	10/05/11
>
> Not a bug in reality.

Actually this one is a real bug, I noticed this myself quite a long time
ago, and under Linux we indeed only handle 1 event per call. So we need to
either fix the docs (what do the Windows / Mac OS X backends do?), or fix
the Linux code. So lets copy this one over.

> ++++++++
>
> As for the enhancement requests, maybe it is a good idea to copy all
> of them except #107.

+1

> How do you like the plan?

Overall I like it, also see my comments above.

Regards,

Hans