HID get report from a mac not as expected

RE: HID get report from a mac not as expected

yiancar — Wed, 20 Jan 2021 08:56:39 GMT

Hey eekwils,

Now having some more experience with macOS and its peripherals I believe that its caveats of the OS.

For example there is another magic report you can send which will show your devices battery life in the macOS bar (like magic mice do etc).

Thank you for replying to my 3 year old question! I deeply appreciate it:)

RE: HID get report from a mac not as expected

eekwils — Wed, 20 Jan 2021 08:32:40 GMT

I know this thread is 3 years old but I think I've found a solution to this issue if anyone else is coming across it.

When using the ble_hids_keyboard example from the SDK I was experiencing the same problem, I would receive a report from macOS but the value of the caps lock bit wouldn't change. As I developed my firmware further I added a consumer control report to the hid device descriptor which meant that I needed to explicitly add a report ID to both the keyboard report and consumer control report. After adding the report ID to the keyboard report the capslock functionality started working on macOS. I haven't had time to fully test that this was the change that did it but I pretty sure it was.

My report descriptor looks like this:

static uint8_t report_map_data[] = 
    {
        0x05, 0x01,       // Usage Page (Generic Desktop)
        0x09, 0x06,       // Usage (Keyboard)
        0xA1, 0x01,       // Collection (Application)
        0x85, 0x01,       // Report ID (1) <---- !!!!This is the bit I added
        0x05, 0x07,       // Usage Page (Key Codes)
        0x19, 0xe0,       // Usage Minimum (224)
        0x29, 0xe7,       // Usage Maximum (231)
        0x15, 0x00,       // Logical Minimum (0)
        0x25, 0x01,       // Logical Maximum (1)
        0x75, 0x01,       // Report Size (1)
        0x95, 0x08,       // Report Count (8)
        0x81, 0x02,       // Input (Data, Variable, Absolute)

        0x95, 0x01,       // Report Count (1)
        0x75, 0x08,       // Report Size (8)
        0x81, 0x01,       // Input (Constant) reserved byte(1)

        0x95, 0x05,       // Report Count (5)
        0x75, 0x01,       // Report Size (1)
        0x05, 0x08,       // Usage Page (Page# for LEDs)
        0x19, 0x01,       // Usage Minimum (1)
        0x29, 0x05,       // Usage Maximum (5)
        0x91, 0x02,       // Output (Data, Variable, Absolute), Led report
        0x95, 0x01,       // Report Count (1)
        0x75, 0x03,       // Report Size (3)
        0x91, 0x01,       // Output (Data, Variable, Absolute), Led report padding

        0x95, 0x06,       // Report Count (6)
        0x75, 0x08,       // Report Size (8)
        0x15, 0x00,       // Logical Minimum (0)
        0x25, 0x65,       // Logical Maximum (101)
        0x05, 0x07,       // Usage Page (Key codes)
        0x19, 0x00,       // Usage Minimum (0)
        0x29, 0x65,       // Usage Maximum (101)
        0x81, 0x00,       // Input (Data, Array) Key array(6 bytes)

        0x09, 0x05,       // Usage (Vendor Defined)
        0x15, 0x00,       // Logical Minimum (0)
        0x26, 0xFF, 0x00, // Logical Maximum (255)
        0x75, 0x08,       // Report Size (8 bit)
        0x95, 0x02,       // Report Count (2)
        0xB1, 0x02,       // Feature (Data, Variable, Absolute)

        0xC0,             // End Collection (Application)

        //Consumer Control report
        0x05, 0x0C,       // Usage Page (Consumer Devices)
        0x09, 0x01,       // Usage (Consumer Control)
        0xA1, 0x01,       // Collection (Application)
        0x85, 0x02,       // Report ID (2)
        0x15, 0x00,       // Logical Minimum (0)
        0x25, 0x01,       // Logical Maximum (1)
        0x75, 0x01,       // Report Size (1)
        0x95, 0x01,       // Report Count (1)

        0x09, 0xCD,       // Usage (Play/Pause)
        0x81, 0x02,       // Input (Data, Value, Relative, Bit Field)
        0x09, 0xB5,       // Usage (Scan Next Track)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0xB6,       // Usage (Scan Previous Track)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0xE2,       // Usage (Mute)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0xE9,       // Usage (Vol Up)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0xEA,       // Usage (Vol Down)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0x6F,       // Usage (Brightness Up)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)
        0x09, 0x70,       // Usage (Brightness Down)
        0x81, 0x02,       // Input (Data,Value,Relative,Bit Field)

        0xC0
    };

And my output report now looks like this:

    #define OUTPUT_REPORT_INDEX   0
    #define OUTPUT_REP_REF_ID     1//<----!!! This must match the report id specified in the descriptor
    #define OUTPUT_REPORT_MAX_LEN 1

    p_output_report                       = &output_report_array[OUTPUT_REPORT_INDEX];
    p_output_report->max_len              = OUTPUT_REPORT_MAX_LEN;
    p_output_report->rep_ref.report_id    = OUTPUT_REP_REF_ID;
    p_output_report->rep_ref.report_type  = BLE_HIDS_REP_TYPE_OUTPUT;

    p_output_report->sec.wr               = SEC_JUST_WORKS;
    p_output_report->sec.rd               = SEC_JUST_WORKS;

I have no idea why specifying a report id would cause macOS to act differently but it seems it does.

I hope this can help anyone who's having this problem!

RE: HID get report from a mac not as expected

yiancar — Tue, 12 Jun 2018 10:53:36 GMT

For anyone still looking into this a solution has not been found

RE: HID get report from a mac not as expected

yiancar — Mon, 11 Sep 2017 12:31:56 GMT

Hello Again Sigurd, Thanks for the links, i created a report in the forum forums.developer.apple.com/.../257980 however I am not willing to pay 99$ to get code level support :P. I am just leaving the link here for future reference if the issue is ever solved.

Yiangos

RE: HID get report from a mac not as expected

Sigurd — Tue, 05 Sep 2017 13:24:03 GMT

Maybe create a post here, and you can also contact apple direclty on this page.

RE: HID get report from a mac not as expected

yiancar — Mon, 28 Aug 2017 14:36:55 GMT

bump, Anyone had a look at this?

RE: HID get report from a mac not as expected

yiancar — Thu, 24 Aug 2017 21:15:58 GMT

Yes same 10.12.6. Is there any dev way to contact Apple perhaps? Also as a work around, I imagine there is no way to tell that its an apple device that the keyboard has connected to (from the nordic side of thinks)

RE: HID get report from a mac not as expected

Sigurd — Thu, 24 Aug 2017 14:55:11 GMT

What version of macOS did you try with? I tested with macOS version 10.12.6 here.

According to the BLE-HID spec, the mac should have sent a Output report containing the Caps lock state, both when the state changes and when you reconnect/connect. It did some sniffer tests, but did not see any on-air packets for the CAPS-lock state being sent unfortunately.

RE: HID get report from a mac not as expected

yiancar — Wed, 23 Aug 2017 06:45:39 GMT

Thank you for having a look Sigurd. As you may understand I am trying to develop a bluetooth keyboard. I could just check for when the capslock key is pressed to turn on the led but this wouldnt be in sync with the actual OS. As a worst case scenario maybe somehow I can detect if its connected to mac or windows and act accordingly?

RE: HID get report from a mac not as expected

Sigurd — Tue, 22 Aug 2017 16:35:52 GMT

Hi,

I have tested this on a MacBook Air, and I'm seeing the same issue here, the caps-lock state is not reported back to the nRF5x-DK. I also tested this on a Windows 8 laptop, but it worked 100% fine on the Windows laptop. So this is a issue with the Mac. I will look for more information about why the mac behaves this way.