On Tue, 7 Sep 2004, Toralf Lund wrote: > >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! > > > > > 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.
In fact I don't know the origins of my first name... although Alan Cox seems to agree that in his case it was Celtic. But that doesn't matter; I'm not talking about ancestry. When I use my name, I'm talking about me -- I'm American and my name is in American English. But I have to agree that notion of the language of a proper name isn't as well defined as it might be. Basically it shouldn't matter too much _which_ language codes you list. But you have to have a non-empty list if you want to use string descriptors. > >No, there isn't any equivalent. If an application doesn't care about the > >language, it will simply use the first one you list. > > > > > 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... Depends on the program. The Linux USB stack always uses the first entry on the list, no matter what. Other programs can do what they please. > 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...) I imagine the closest thing to a "lingua franca" would be U.S.-English, but obviously my viewpoint is biased. > >>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? > > > > > 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. Hmmm. So if you were sending a bulk-in response, and the response length was exactly what the host expected _and_ was a multiple of the maxpacket size, and if you set that flag, then the _next_ time the host sends a bulk-in request on that same endpoint the hardware will automatically transmit a zero-length packet, assuming you hadn't yet queued any data in the FIFO. This would be a race -- you could only guarantee that everything would work right _if_ you were fast enough to queue the data before the host requested it. On the other hand, if you don't set the flag then there's no problem at all. 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
