А вы когда нибудь видели строковые дескрипторы на нац. языках?

а почему бы и нет? Если по стандарту можно

Ну можно-то можно, но нахрена? Если в итоге ни единого девайса с нацдескриптором я в жизни не видел.

ок, если когда-нибудь приспичит сделать USB девайс, сделаю дескриптор на китайском или грузинском :)

Такие?

Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: new high-speed USB device number 9 using ehci_hcd
Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: New USB device found, idVendor=4102, idProduct=1041
Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: Product: iriver E100
Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: Manufacturer: iriver
Feb 13 17:35:11 Tarkus kernel: usb 2-5.4: SerialNumber: 单䑂卉K

Лучше не надо. От таких дескрипторов некоторые хосты (особенно во всяких ртосинах) имеют обычкновения крошить систему.

получится девайс-убийца :) Таким хорошо будет тестировать реализацию USB на соответствие стандартам

сами строки в уникоде

В каком конкретно?

USB strings use UNICODE encoded characters (16-bits each)

похоже на UTF-16 little endian

Юникод — это просто стандарт, в котором все символы пронумерованы. А кодировки (правила по которым последовательность символов преобразуется в байтики) есть разные. 16-бит — это либо UTF-16, либо UCS-2.

Вот полный пример того, как оно в итоге выглядит

const uint8_t Virtual_Com_Port_StringVendor[VIRTUAL_COM_PORT_SIZ_STRING_VENDOR] =
  {
    VIRTUAL_COM_PORT_SIZ_STRING_VENDOR,     /* Size of Vendor string */
    USB_STRING_DESCRIPTOR_TYPE,             /* bDescriptorType*/
    /* Manufacturer: "STMicroelectronics" */
    'S', 0, 'T', 0, 'M', 0, 'i', 0, 'c', 0, 'r', 0, 'o', 0, 'e', 0,
    'l', 0, 'e', 0, 'c', 0, 't', 0, 'r', 0, 'o', 0, 'n', 0, 'i', 0,
    'c', 0, 's', 0
  };

И это так обалденно редактировать...

Что я подобные костыли рожаю:

#!/bin/bash
LEN=${#2}
case "$3" in
"str")
  echo -n "$1="
  echo "$2" |while read -n 1 char; do
  if [ "${char}" != "" ]; then
  LEN=$((LEN-1))
  if [ "${char}" == "'" ]; then
          char="\'"
          fi
   if [ "${char}" == "_" ]; then         
          char=" "
          fi
          
  echo -n "'${char}'"
  if [ "$LEN" -gt "0" ]; then
  echo -n ","
  fi
  fi
  done
  echo -e ""
  
  ;;
"len")
  echo $1_LEN=$LEN
  ;;
esac

Честно, не спец по сортам юникода, но думаю что тупо UTF-16.

кстати, а посмотри langid сернума. оно могло высрать сырые данные регистров серийного номера, которые текстом так проинтерпретировались. Я часто такое встречал.

[    2.819554] usb 2-1.1: Product: F3307
[    2.819563] usb 2-1.1: Manufacturer: \xffffffc3\xffffff9b^KF3307
[    2.819572] usb 2-1.1: SerialNumber: 3526410400167550

оно?

Кстати, сначала думал, что так сделали для того, чтобы ресурсы сэкономить. А фигвам: по-моему, учитывая то, что таких идентификаторов дофига, проще было строковые переменные посохранять, а потом нули к каждой букве понадобавлять.

Тем паче, не так-то часто эти дескрипторы запрашивают.

Но согласен: стек USB какой-то дегенерат придумывал. Это ж надо додуматься туда запихать не ASCII, а долбаный юникод.

а L"STmicroelectronics" не даст то же самое?

У ST вообще софтом гоблины занимаются, которые испытывают оргазм от особенно длинных имен функций написанных Весьма_Стремным_Стилем.

Есть такое. Я поначалу было подумал переписать их библиотечки, но поковырявшись в этом ужасе, понял, что проще с нуля самому написать. Вот и оставил, как есть. Хрен с ними.

Это даст:
1.c:1:1: error: char-array initialized from wide string

Аналогично, особенно учитывая, что кроме как на самом нижнем уровне они обычно не болтаются.

Можно написать свое для преобразования: на входе брать нормальную строку, на выходе отдавать извращенную. Да еще и длину считать.

Но просто не так-то часто эти дескрипторы заполняются. Видимо, ST-шные инженеры из того и исходили, что раз в несколько лет вручную эту хрень заполнить несложно будет. Сложней остальную логику реализовать.

(char[])L"STmicroelectronics"

а вот так? :) Хотя подозреваю, что не скомпилится

точнее можно структурку для строки объявить, с масивом wchar_t. Это если wchar_t в UTF-16

Не, не соберет.
Я для экономии места во флеше тупо добавил костыль, который в рантайме по запросу генерирует из ASCII, думаю это самое нормальное будет решение.

А есть способы более ленивые, чем написание небольшой программы на libusb и ковыряние во внутренностях ядра?

Забей, по ходу оно через lsusb не отображается.

Нет. В линуксе wchar_t - это UCS-4, т.е. 4 байта. А вот в винде wchar_t это UCS-2, т.е. 2 байта.