On Tue, 7 Sep 2004, Toralf Lund wrote:
> >I would list first the actual language those strings are written in.
> >
> They're names, and as such are not written in any language. Or that
> depends on how you see it, I guess, but at least they don't have a
> language in the same sense as descriptive texts would.
Well, do your best. Try to use whatever language the names are native to.
Hint: If a name contains a special character that doesn't belong to a
language, then the name isn't in that language!
> Is there really no way to encode the concept of texts that are valid for
> all languages, besides actually including the full language list? Or
> alternatively, include a "generic" language? I guess what I'm looking
> for is a USB language code equivalent to the "C" (or "POSIX") locale.
No, there isn't any equivalent. If an application doesn't care about the
language, it will simply use the first one you list.
> Fair enough... However, I think the question is really whether there's
> any point in using the 2.0 spec when you don't expect to be able to
> support anything that was introduced after 1.1.
The point is that the 2.0 spec is more complete and detailed than the 1.1
spec. It ties up more loose ends and is less ambiguous.
> >No, it isn't. If the controller manual says that then it's wrong.
> >
> >
> It says
>
> The user starts by determining the number of packets in the data
> block, based on the maximum packet size of the target endpoint.
>
> When the number of packets is an integer, the transfer ends on a
> packet boundary. A zero length packet is required to terminate the
> transfer. When the number of packets is not an integer, the last
> packet of the transfer is a short packet and no zero length packet
> is required.
That is definitely wrong. A zero length packet is _not_ required to
terminate a transfer if the total length of the previous packets is equal
to what the host was expecting.
Here's a reference to the 2.0 spec that is unambiguous (unfortunately
there are a couple of other places in the spec that _are_ ambiguous and
have probably contributed toward confusing manufacturers). I bet you can
find this text in the 1.1 spec too. In Chapter 5 (USB Data Flow Model),
section 5.5.3 (Control Transfer Packet Size Constraints) says this:
The Data stage of a control transfer from an endpoint to the host is
complete when the endpoint does one of the following:
o Has transferred exactly the amount of data specified during the
Setup stage
o Transfers a packet with a payload size less than wMaxPacketSize
or transfers a zero-length packet
Similar text is present in section 5.8.3 (Bulk Transfer Packet Size
Constraints), except there it's the amount of data expected instead of the
amount specified during the Setup stage.
So if the amount requested is a multiple of the maxpacket size, the first
condition is satisified as soon as all the requested data has been
transferred. The host won't ask for any more (why should it?) and the
device shouldn't try to transmit a zero-length packet.
> >It doesn't matter for control transfers. But for bulk or interrupt
> >transfers it _does_ matter. Your zero-length packet will remain in the
> >endpoint's queue and will get sent as the response to the next bulk-in or
> >interrupt-in transfer, leading the host to think that no data is available
> >(since the zero-length packet is a short packet that will terminate the
> >transfer).
> >
> >
> I don't actually put a zero-length packet in the FIFO, though. What I
> was trying to say, is that the controller has special logic for this;
> you can request "zero-length packet send" via a special control register
> bit. I think it may be assumed that setting this bit will *not* cause it
> to use the zero-length packet as a response to the next transfer.
It won't? Then what _does_ it do?
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
