SDP (Service Discovery Protocol) — протокол обнаружения сервисов. Здесь мы не будем подробно вникать в его предназначение, а укажем только ссылку на русскоязычное описание данного протокола. Кому интересно, может почитать. Нас будет интересовать сервисная запись (Service Record), поскольку она действительно является самой важной частью работы устройства bluetooth. Благодаря сервисной записи наш КПК и будет определяться как HID мышь.
Самое сложное в реализации сервисной записи — это настройка сервисных атрибутов (впрочем, если поискать в сети, то можно найти готовые примеры сервисной записи для мышки). Каждый атрибут имеет свое название и свой уникальный номер. Сложность в реализации заключается не столько в подготовке самой записи, сколько в разном ее представлении для различных стеков на уровне исходных кодов . Так, для стека Broadcomm, при формировании записи необходимо инициализировать каждый атрибут, а для стека Microsoft необходима монолитная структура записи. При формировании записи необходимо учитывать какие именно атрибуты необходимы для HID устройства. В спецификации Bluetooth HID в таблице 18 и 19 описаны все атрибуты с пометкой их обязательности.
Сейчас мы попытаемся на примерах разобрать некоторые атрибуты.Кстати, интерпретация каждого байта записи — это отдельная песня, хорошо описанная в спецификации SDP. И так начнем:
— ServiceClassIDList: — этот атрибут указывает тип сервиса, предоставляемого записью
0x09, //следующие 2 байта представляют собой беззнаковое целое
0x00, 0x01, //ServiceClassIdList (AttribID = 0x0001)
0x35,0x03, //сегмент элемента данных длиной 3 байта
0x19, //следующие 2 байта это UUID
0x11, 0x24, //uuid HID (0x1124) ВОТ ЭТОТ ТИП СЕРВИСА !!!
— ProtocolDescriptorList: — этот атрибут описывает протоколы, которые могут использоваться для доступа к сервису
0x09, //следующие 2 байта представляют собой беззнаковое целое
0x00, 0x04, //ProtocolDescriptorList(AttribID = 0x0004)
0x35,0x0d, //сегмент элемента данных длиной 13 байт
0x35,0x06, //сегмент элемента данных длиной 6 байт /* DataElSeq 6 bytes for L2CAP Descriptor*/
0x19, //следующие 2 байта это UUID
0x01,0x00, // uuid L2CAP(0x0100) БУДЕТ ИСПОЛЬЗОВАТЬСЯ ПРОТОКОЛ L2CAP…
0x09, //следующие 2 байта представляют собой беззнаковое целое
0x00,0x11, //PSM HID_Control = 0x0011 …ПО КАНАЛУ УПРАВЛЕНИЯ = 0x0011
0x35,0x03, //сегмент элемента данных длиной 3 байта
0x19, //следующие 2 байта это UUID
0x00,0x11, //uuid HIDP(0x0011) БУДЕТ ИСПОЛЬЗОВАТЬСЯ ПРОТОКОЛ HID
Для расширения описания протоколов, указанных в ProtocolDescriptorList, применяется атрибут AdditionalProtocolDescriptorList
— AdditionalProtocolDescriptorList
0x09, //следующие 2 байта представляют собой беззнаковое целое
0x00,0x0d, //AdditionalProtocolDescriptorList(AttribID = 0x000D)
0x35, 0x0f, //сегмент элемента данных длиной 15 байт
0x35, 0x0d, //сегмент элемента данных длиной 13 байт
0x35, 0x06, //сегмент элемента данных длиной 6 байт
0x19, //следующие 2 байта это UUID
0x01,0x00, // uuid L2CAP(0x0100) БУДЕТ ИСПОЛЬЗОВАТЬСЯ ПРОТОКОЛ L2CAP…
0x09, //следующие 2 байта представляют собой беззнаковое целое
0x00,0x13, //PSM HID_Interrupt = 0x0013 …ПО КАНАЛУ ПРЕРЫВАНИЯ = 0x0013
0x35, 0x03, //сегмент элемента данных длиной 3 байта
0x19, //следующие 2 байта это UUID
0x00,0x11, //uuid HIDP(0x0011) БУДЕТ ИСПОЛЬЗОВАТЬСЯ ПРОТОКОЛ HID
Вот таким образом формируются и остальные атрибуты.
Самым существенным атрибутом является HIDDescriptorList, описывающий поведение устройства и данные, им передаваемые, путем определения дескрипторов, описанных в спецификации «USB Device Class Definition for HID». Атрибут содержит от одного до нескольких дескрипторов, каждый из которых представлен последовательностью элементов данных. Подробное описание данного дескрипторов HID заняло бы очень много места, т.к. только спецификация «USB Device Class Definition for HID» объемом 168 страниц. Кому интересно, может ее просто почитать. По этому я просто приведу пример рабочего атрибута:
0x09, /* HIDDescriptorList(0x0206) */ /*61 (65)*/
0x02,
0x06,
0x35, 0x38, /*0x3c*/ /* DataElSeq 56(60) bytes */
0x35, 0x36, /*0x3a*/ /* DataElSeq 54(58) bytes */
0x08, 0x22, /*uint8 0x22 Type = report descriptor */
0x25, 0x32, /*0x36*/ /*text string 50(54) byte report descriptor*/
0x05,0x01, /*USAGE_PAGE general desktop*/
0x09,0x02, /*USAGE Mouse*/
0xa1,0x01, /*COLLECTION Aplication*/
0x09,0x01, /*USAGE Pointer*/
0xa1,0x00, /*COLLECTION Physical*/
//0x85,0x02, /*REPORT_ID (2)*/
0x05,0x09, /*USAGE_PAGE Button*/
0x19,0x01, /*USAGE_MINIMUM (Button 1)*/
0x29,0x03, /*USAGE_MAXIMUM (Button 3)*/
0x15,0x00, /*LOCAL_MINIMUM (0)*/
0x25,0x01, /*LOCAL_MAXIMUM (1)*/
0x95,0x03, /*REPORT_COUNT (3)*/
0x75,0x01, /*REPORT_SIZE (1)*/
0x81,0x02, /*INPUT (Data,Var,Abs)*/
0x95,0x01, /*REPORT_COUNT (1)*/
0x75,0x05, /*REPORT_SIZE (5)*/
0x81,0x03, /*INPUT (Cnst,Var,Abs)*/
0x05,0x01, /*USAGE_PAGE general desktop*/
0x09,0x30, /*USAGE X*/
0x09,0x31, /*USAGE Y*/
//0X09,0X38, /*USAGE WHEEL*/
0x15,0x81, /*LOCAL_MINIMUM (-127)*/
0x25,0x7f, /*LOCAL_MAXIMUM (127)*/
0x75,0x08, /*REPORT_SIZE (8)*/
0x95,0x02, /*REPORT_COUNT (2)*/
0x81,0x06, /*INPUT (Data,Var,Rel)*/
0xc0, /*END_COLLECTON*/
0xc0, /*END_COLLECTON*/
Согласен, что все сложно. Я разбирался с этими цифрами недели полторы :).
Если Вы заметили, в структуре атрибута есть 2 заремленные строки.
— //0x85,0x02, //REPORT_ID (2) означает что это report от мышки, но т.к. он нужен только для того, что бы мышь была видна при загрузке компьютера (при поддержке HID-устройством т.н. boot protocol-а), когда еще BIOS ищет устройства, по этому строка и закомментирована.
— //0X09,0X38, //USAGE WHEEL — означает, что мышь будет с «колесиком» 🙂
Не сложный, но довольно таки муторный метод создания сервисной записи 🙂 Кстати для облегчения создания HIDDescriptorList есть хорошая утилита под названием «HID Descriptor Tool». Ее можно найти в интернете или взять у меня.