Actually, our company name is strictly speaking Latin, but I don't think it would be right to say that in the USB descriptors. Just like you probably wouldn't encode your first name as Celtic (which I think it originally is), or translate it into English or whatever... Seems to me that the standard is somewhat lacking in this respect... Not that I mind *that* much - see below.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.I would list first the actual language those strings are written in.
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!
What if it does care, but doesn't find what it wants? Will it still use the first? If I can assume that's the case, then I'm quite happy after all... Of course, the device id strings are just minor details, anyway, but the device/software will definitely be used with different language settings, and it's a bit hard to anticipate which exactly (depends on where the equipment is sold...)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.
OK. I assumed the 1.1 one would be simpler and thus better to use since I don't want any of the 2.0 (only) features, but I guess I was wrong...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.
Somehow that doesn't surprise me. The producer seems better at making hardware than writing manuals... I'm talking about a major electronics company whose name I won't mention here...
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.
*Cough!* I think I got something stuck... Motorola... in by throat. *Cough*...
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).
OK. Thanks
It (supposedly) inserts a zero-length package, if data is requested while the transmit FIFO is empty and the "zero-length packet send" flag is set. The flag is reset after this has happened, I think.
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?
- Toralf
------------------------------------------------------- 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
