Problem with some keys using nRF Desktop with iPad/Apple products

Hi,

My customer tried using the keyboard we made based on nRF Desktop with NCS version 2.1.0 with an iPad and noticed that most of the keys work, but space bar does not, and caps lock does not.

I suspected something was up with the HID descriptor so I've been digging into that all day, and I've been troubleshooting it using an nRF52840-DK with the excellent Nordic-provided Bluetooth sniffer code on it with Wireshark.

I found that the keyboard is advertising that its report map is at characteristic handle 3a, but when the iPad tries to read the report map from that characteristic it fails. So the iPad not getting the HID report map might explain the strange behavior I'm seeing.

I turned on RTT debugging and I see the error happening there, too: "bt_l2cap: Ignoring data for unknown channel ID 0x003a"

I tried searching for that error text and I found a DevZone post about it where Nordic Support declared that it was no big deal and could be ignored, but it seems too much of a coincidence that this could explain the issues I'm having.  That support ticket is here:

 Bluetooth: Ignoring data for unknown channel ID 0x003a 

That characteristic is under the BT_UUID_HIDS_REPORT_MAP_VAL characteristic (0x2a4b) I found in \nRF_Connect\v2.1.0\zephyr\include\zephyr\bluetooth\uuid.h

but so far I haven't found the place in the Bluetooth code that associates the channel ID of 3a with the report map.

Help! Has this perhaps been solved in a later version of NCS? I've avoided upgrading because a lot of stuff has changed in NCS since I started this project and the last time I tried upgrading the error list I got make it seem like it was going to be a lot of work to upgrade.

I've attached a couple of screenshots from my Wireshark capture showing where the device is advertising its report map on 3A and then throwing an error when the host tries to read it.

Thanks,

Glen

Parents
  • I just tried it using my second nRF52840-DK with the latest NCS 2.61 and a new instance of nRF Desktop. The ID has changed slightly, but the error still exists.

  • Hi!

    Glen M said:
    I just tried it using my second nRF52840-DK with the latest NCS 2.61 and a new instance of nRF Desktop.

    This was with out-of-the-box nrf_desktop application?

    ith an iPad and noticed that most of the keys work, but space bar does not, and caps lock does not.

    Is it only on the iPad /iOS this is an issue? Does it work as expected on Windows and Android ?

    BR,

    Sigurd

  • Hi!

    I see the same behavior as you describe. On Windows and Android it works, but not on iPad or iPhone. So seems like something with the keyboard AND the mouse reports confuses the iOS device.

    I have been looking into what's happening on-air

    On Android when I press and release button 2(Caps-lock button):

    we see that the android responds back with ATT Write Command Packet,  basically confirming back to the nRF52 that caps-lock is on.

    On iPad, we don't get this ATT Write Command Packet back.

    But interestingly, I'm seeing 2 packets per key press/release. 2 Packet for button-press, and then 2 for button-release. So that's seem like a bug, not sure yet if it's relevant for the issue or not. Will continue debugging this.

  • Hi Sigurd,

    I've been experimenting more with this. I found that CONFIG_DESKTOP_HID_REPORT_KEYBOARD_SUPPORT is not included in the project by default, so I added it. Now, the keyboard stuff is working - but the mouse stuff is broken on both my Windows PC and the iPad.

    Does that mean that including both things in one report is just broken and perhaps the problem with the iPad just stems from the keyboard stuff not being included in the descriptor prior to me adding in that define?

    EDITED: Ok I found that my mouse wasn't working because I had turned off the enables for that in my main project while testing previously. Turning the mouse stuff back on gets be right back where I started. So I guess I'm back to the hypothesis that the combined report just doesn't work for some reason.

  • Hi!

    Glen M said:
    So I guess I'm back to the hypothesis that the combined report just doesn't work for some reason.

    That's my hypothesis as well, that apple devices does not support that. But I have asked the nrf_desktop developers to look into this as well now.

  • Here's some more info. I have an ARTECK HD197 keyboard/trackpad combo that works properly with my iPad. I noticed when checking out its Bluetooth characteristics that it identifies as a Nordic Semiconductor device.

    Attached is a zip file containing a Wireshark capture of it communicating with my iPad, and a bunch of screenshots I took with my phone showing its Bluetooth characteristics.

  • Hi!

    Update: nrf_desktop developers have found a workaround. Reordering HID keyboard and HID mouse reports definitions in HID report map (placing HID keyboard report before HID mouse report) seems to workaround the issue somehow. We are investigating further.

    /*
     * Copyright (c) 2019 Nordic Semiconductor ASA
     *
     * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
     */
    
    #include <zephyr/types.h>
    
    #include "hid_report_desc.h"
    
    const uint8_t hid_report_desc[] = {
    
    #if CONFIG_DESKTOP_HID_REPORT_KEYBOARD_SUPPORT
    	0x05, 0x01,     /* Usage Page (Generic Desktop) */
    	0x09, 0x06,     /* Usage (Keyboard) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_KEYBOARD(REPORT_ID_KEYBOARD_KEYS, REPORT_ID_KEYBOARD_LEDS),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE && !CONFIG_DESKTOP_HID_REPORT_MOUSE_SUPPORT
    	REPORT_MAP_USER_CONFIG(REPORT_ID_USER_CONFIG),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_OUT_REPORT
    	REPORT_MAP_USER_CONFIG_OUT(REPORT_ID_USER_CONFIG_OUT),
    #endif
    #endif
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_MOUSE_SUPPORT
    	0x05, 0x01,     /* Usage Page (Generic Desktop) */
    	0x09, 0x02,     /* Usage (Mouse) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_MOUSE(REPORT_ID_MOUSE),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE
    	REPORT_MAP_USER_CONFIG(REPORT_ID_USER_CONFIG),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_OUT_REPORT
    	REPORT_MAP_USER_CONFIG_OUT(REPORT_ID_USER_CONFIG_OUT),
    #endif
    #endif
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_SYSTEM_CTRL_SUPPORT
    	0x05, 0x01,     /* Usage page (Generic Desktop) */
    	0x09, 0x80,	/* Usage (System Control) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_SYSTEM_CTRL(REPORT_ID_SYSTEM_CTRL),
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_CONSUMER_CTRL_SUPPORT
    	0x05, 0x0C,	/* Usage page (Consumer Control) */
    	0x09, 0x01,     /* Usage (Consumer Control) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_CONSUMER_CTRL(REPORT_ID_CONSUMER_CTRL),
    	0xC0,           /* End Collection (Application) */
    #endif
    };
    
    const size_t hid_report_desc_size = sizeof(hid_report_desc);
    

Reply
  • Hi!

    Update: nrf_desktop developers have found a workaround. Reordering HID keyboard and HID mouse reports definitions in HID report map (placing HID keyboard report before HID mouse report) seems to workaround the issue somehow. We are investigating further.

    /*
     * Copyright (c) 2019 Nordic Semiconductor ASA
     *
     * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
     */
    
    #include <zephyr/types.h>
    
    #include "hid_report_desc.h"
    
    const uint8_t hid_report_desc[] = {
    
    #if CONFIG_DESKTOP_HID_REPORT_KEYBOARD_SUPPORT
    	0x05, 0x01,     /* Usage Page (Generic Desktop) */
    	0x09, 0x06,     /* Usage (Keyboard) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_KEYBOARD(REPORT_ID_KEYBOARD_KEYS, REPORT_ID_KEYBOARD_LEDS),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE && !CONFIG_DESKTOP_HID_REPORT_MOUSE_SUPPORT
    	REPORT_MAP_USER_CONFIG(REPORT_ID_USER_CONFIG),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_OUT_REPORT
    	REPORT_MAP_USER_CONFIG_OUT(REPORT_ID_USER_CONFIG_OUT),
    #endif
    #endif
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_MOUSE_SUPPORT
    	0x05, 0x01,     /* Usage Page (Generic Desktop) */
    	0x09, 0x02,     /* Usage (Mouse) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_MOUSE(REPORT_ID_MOUSE),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_ENABLE
    	REPORT_MAP_USER_CONFIG(REPORT_ID_USER_CONFIG),
    #if CONFIG_DESKTOP_CONFIG_CHANNEL_OUT_REPORT
    	REPORT_MAP_USER_CONFIG_OUT(REPORT_ID_USER_CONFIG_OUT),
    #endif
    #endif
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_SYSTEM_CTRL_SUPPORT
    	0x05, 0x01,     /* Usage page (Generic Desktop) */
    	0x09, 0x80,	/* Usage (System Control) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_SYSTEM_CTRL(REPORT_ID_SYSTEM_CTRL),
    	0xC0,           /* End Collection (Application) */
    #endif
    
    #if CONFIG_DESKTOP_HID_REPORT_CONSUMER_CTRL_SUPPORT
    	0x05, 0x0C,	/* Usage page (Consumer Control) */
    	0x09, 0x01,     /* Usage (Consumer Control) */
    	0xA1, 0x01,     /* Collection (Application) */
    	REPORT_MAP_CONSUMER_CTRL(REPORT_ID_CONSUMER_CTRL),
    	0xC0,           /* End Collection (Application) */
    #endif
    };
    
    const size_t hid_report_desc_size = sizeof(hid_report_desc);
    

Children
No Data
Related