Alan Stern wrote:
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.On Mon, 6 Sep 2004, Toralf Lund wrote:
Another minor question: How do you set up the list of supported languages when you don't actually support any languages, or support all of them, depending on how you see it? I mean, I only return strings for the manufacturer name and product id, and those are never translated; I return the same thing regardless of what language is requested.
I would list first the actual language those strings are written in.
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.
Then maybe add U.S.-English as a second language because so many applications use it -- but not if the strings contain any non-English characters (accented characters, for example).
Really? I was thinking I should use 1.1 because the controller only supports USB 1.1, but perhaps that was not a correct assumption...By the way ... you should switch to using the 2.0 spec.
What makes you think the controller doesn't support USB 2.0?
Just that the manual says it complies with USB 1.1...
To a very large degree the specification is upward compatible; that is, a controller that supports USB 1.1 is also a valid USB 2.0 controller.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.
Remember, the fact that it doesn't run at high speed is unimportant. True, high speed was introduced with the 2.0 spec; but the spec says specifically that devices which only run at low or full speed are still compatible.
[ ... ]
Ah, nothing more than that. I'm already trying to do this. But doesn't this rule always apply? After reading the controller manual, I was lead to believe that you have to send a null-packet to terminate the transfer in *all* cases where the data size is an integer multiple of maxpacket, even when M = N in the above terminology. Isn't that correct?When your descriptor is N bytes, and the host requests M bytes, you must return MIN(N,M) bytes in one or more IN DATA packets as requested by the host.
That "short packet" rule adds: If that value is not M, and it's an exact multiple of ep0 maxpacket size, then you must also send a zero length IN DATA packet.
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.
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.Maybe it makes no real difference to me; I think that when I tell the controller to end with a zero-length packet, it will only do so if the host actually requests data at the point where it would be transferred.
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).
- 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
