Reputation: 31
I've been working on small project to emulate Bluetooth HID device, based on embedded linux, Bluez with python implemented code. The idea is to look for input events on keyboards and mouse devices, parse it and forward to a bluetooth host. It is going fine, except for the mouse behavior on Windows.
On Android and Linux targets, the mouse behave just fine: buttons, scroll and movements work as expected. However, on Windows targets, the following is observed:
I've devised a USB HID descriptor which is embedded on the SDP record, including definitions for scroll, presented below - if correctly parsed by https://eleccelerator.com/usbdescreqparser/ :)
Any thoughts on this matter?
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x06, // Usage (Keyboard)
0xA1, 0x01, // Collection (Application)
0x85, 0x01, // Report ID (1)
0xA1, 0x00, // Collection (Physical)
0x05, 0x07, // Usage Page (Kbrd/Keypad)
0x19, 0xE0, // Usage Minimum (0xE0)
0x29, 0xE7, // Usage Maximum (0xE7)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x75, 0x01, // Report Size (1)
0x95, 0x08, // Report Count (8)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0x81, 0x01, // Input (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x08, // Report Count (8)
0x75, 0x08, // Report Size (8)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x65, // Logical Maximum (101)
0x05, 0x07, // Usage Page (Kbrd/Keypad)
0x19, 0x00, // Usage Minimum (0x00)
0x29, 0x65, // Usage Maximum (0x65)
0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0, // End Collection
0xC0, // End Collection
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x02, // Usage (Mouse)
0xA1, 0x01, // Collection (Application)
0x85, 0x02, // Report ID (2)
0x09, 0x01, // Usage (Pointer)
0xA1, 0x00, // Collection (Physical)
0x05, 0x09, // Usage Page (Button)
0x19, 0x01, // Usage Minimum (0x01)
0x29, 0x03, // Usage Maximum (0x03)
0x15, 0x00, // Logical Minimum (0)
0x25, 0x01, // Logical Maximum (1)
0x75, 0x01, // Report Size (1)
0x95, 0x03, // Report Count (3)
0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x05, // Report Size (5)
0x95, 0x01, // Report Count (1)
0x81, 0x01, // Input (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x30, // Usage (X)
0x09, 0x31, // Usage (Y)
0x09, 0x38, // Usage (Wheel)
0x15, 0x81, // Logical Minimum (-127)
0x25, 0x7F, // Logical Maximum (127)
0x75, 0x08, // Report Size (8)
0x95, 0x03, // Report Count (3)
0x81, 0x06, // Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0xC0, // End Collection
0xC0, // End Collection
// 104 bytes
Upvotes: 2
Views: 403
Reputation: 31
Found the issue. There were a few actually.
First, the service record for the bluetooth profile (not posted on the original post) was illy formed: it had issues on attribute 0x0009 (BluetoothProfileDescriptorList), which was not properly setting what is supposed to set: the profile version, as per HUMAN INTERFACE DEVICE PROFILE 1.1 Bluetooth Specification. Once I've got that right, the mouse started working but then again the keyboard quit on me.
Then, I noticed that the boilerplate HID descriptor I was using expected me to send 8 bytes for active keys, as it read (see original post):
...
0x95, 0x08, // Report Count (8)
0x75, 0x08, // Report Size (8)
...
And I was sending only 6 bytes on the report. After I got that right, windows accepted input correctly from both mouse and keyboard.
After all, it seems that HIDP implementations for Linux are more lenient than windows'.
(Typed from the custom keyboard and mouse combo device itself :D)
Upvotes: 1