David Brownell wrote:
On Friday 03 September 2004 2:53 am, Toralf Lund wrote:No, I just meant "what kind" as in "which encoding". I can't find any references to encoding or "UTF" in the spec, but never mind that - after changing to UTF-16, everything seems to work fine; my strings are correctly displayed in usbview now. I don't know why I didn't try this earlier...
1. The USB 1.1 spec says "String descriptors use UNICODE encodings".
Which annoys me a great deal, as it fails to specify *what kind
unicode*. Should the string be in UTF-8 format, or 16 or 32-bit?
UTF16-LE, as it says somewhere in the spec. The host must handle
any version of Unicode though (including 3.0, which starts to use
surrogate pairs). The encoding (UTF) doesn't affect what kind of
Unicode you use.
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.
By the way ... you should switch to using the 2.0 spec.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...
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?
2. My string is shorter than the wLength (0xff), which is a situation
I suppose I need to handle specially, but I'm not sure I
understand exactly how. The spec also says (in section 9.4.3): "If
the descriptor is shorter than the wLength field, the device
indicates the end of the control transfer by sending a short
packet when further data is requested," but what exactly does this
mean?
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.
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.
Yeah. I was hoping I could. I haven't really designed the software to handle "request completion". But I was a bit confused by the string descriptor section in the spec, as you may have guessed.Then, as usual, the host sends an empty OUT DATA.
Should I assume that "further data is requested" when the 2nd request is received?
No, that's an entirely separate request; when SETUP arrives, forget about "completing" any previous request.
Even if
you want to send more IN DATA packets, or you're waiting
for the OUT DATA status (etc).
OK.
Thanks for your help,
- T
------------------------------------------------------- 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
