On Mon, 13 Jan 2003, Roger Lindsjo wrote:
>On Sat, 11 Jan 2003 [EMAIL PROTECTED] wrote:
>
>> On Sat, 11 Jan 2003, Roger Lindsjo wrote:
>>
>After looking some more at the specs I realized that some methods actually
>use Hungarian Notation (i -> Index, bcd -> BCS, id -> ID) but sometimes b
>is used that could be number or protocol, and w is word...
yep, there are several types, 'bm' for bitmap, 'b' for byte, 'w' for word,
'i' for string index, and then 'id' is completely different, since it's a
word... I don't think there are any direct name-conflicts, but it's
close, e.g. the device descriptor has 'iProduct' and 'idProduct'...
>I think your original idea is better, keep it the same as the specs (even
>though I think it is ugly) since this will probably make it easier for
>developers familiar with the USB specs to use this implementation.
k, sounds good to me.
>> >This issue is still foggy to me. Does anyone here have the 2 books
>> >referenced at page 205 in the usb spec? ("The Unicode Standard, Worldwide
>> >Character Encoding, Version 1.0 Volume 1 & 2" The Unicode Consortium,
>> >Addison-Wesley Publishing Company.) Section 9.6.5 in the USB specs only
>> >says UNICODE encodings, but to me this gives a whole range of possible
>> >encodings. And there is no way (that I can see) to find out which encoding
>> >is used. I'm guessing UTF-8 is used, but I do not know.
>>
>> I believe it's UTF-16 Little-Endian. In the StringDescriptor RI
>> implementation, I try to use several encoding that are usually present,
>> and default to ASCII (only if the string is pure 8-bit, i.e. no high bytes
>> are non-zero). From what I could find in Java documentation, the best
>> (only?) encodings to use are: "UnicodeLittleUnmarked", "UnicodeLittle",
>> and "UTF-16LE". For more platforms and JVMs, that should work, but it's
>> possible none of those are present, maybe for J9 or something. J9 is
>> crazy.
>
>Yeah, seems reasonable, but you'd think that with such a massive spec as
>this is there wouldn't be ambiguities like this.
Yeah, they could have said 'the strings are UTF-16' (I assume) instead of
being ambiguous and saying 'they are Unicode'. The Unicode website lists
only UTF-8 (variable width), UTF-16 (mostly 16-bit), and UTF-32 (fixed
32-bit width), and since the string descriptors use 16 bits per
character, I assumed UTF-16...then I looked at the Java encoding support
webpage:
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
so for Java 1.3, the decoding should always be possible, but Java 1.0 or
1.1 may not be, or for a J2ME. Still assuming, of course, UTF-16
little-endian. It seems to work for the devices I've tried so far, but I
suspect 99% of devices using langid 0x0409 (US English) will be ASCII,
with the exception of 'copyright' and 'TM' and such...
>the waitUntilComplete is only in DefaultUsbIrp, not in UsbIrp. What is
>your reasoning here? Do you anticipate implementations where UsbIrps could
>not perform this "operation"?
I was thinking about that too, and they are useful methods. I only took
them out because they weren't actually essential methods. Putting them in
forces all UsbIrp implementations to implement them, although that's not
too hard. Probably 99.999% of users will use either the DefaultUsbIrp or
UsbPipe.createUsbIrp()...
Unless anyone thinks they should stay out, I can put them back in to the
interface.
--
Dan Streetman
[EMAIL PROTECTED]
---------------------
186,272 miles per second:
It isn't just a good idea, it's the law!
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
javax-usb-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
