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

[Glen M]

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

[Glen M]

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.

[Sigurd]

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

[Glen M]

Yes - just nrf_desktop as provided with an nRF52840-DK.

I just tried it with Windows and the communication looked different - I see it reading some characteristics but it never asks for the report map and right around where I would expect to see the packets of interest it starts saying "Encrypted packet decrypted incorrectly" so I think I'm missing the important stuff (this happened two tries in a row). I'll attach the Windows and iPad logs below.

Since the real customer-visible symptom of my problem is turning on caps lock and getting the LED output report back from the host that it's been turned on, I'm going to spend the rest of my morning modifying two stock nrf desktop builds, one with SDK version 2.1.0 and one with 2.6.1, to control the caps lock and to turn on a devkit LED when we receive a caps lock indication in the output report. That will at least tell me if the new NCS version would fix my issue, regardless of this HID error.

Upgrading is daunting though. I spent all day yesterday trying to upgrade and I didn't get very far as so much has changed. I got stuck trying to get the project configuration for mcuboot to work under 2.6.1.

nrf_desktop v2p61 connecting to iPad.pcapngnrf_desktop v2p61 connecting to Windows PC.pcapng

[Glen M]

Ok I was able to make the caps lock key work and I was able to get the caps lock status information from the HID output report on the devkit on both NCS version 2.6.1 and on 2.1.0 with both my Windows PC and this iPad.

So apparently whatever this HID report error is it's not the source of my real problem. So for now I'm going to stick with 2.1.0 and see if I can figure out what's going wrong.

Edited to say: I think I came to the wrong conclusion here - I confirmed that a devkit running either 2.6.1 or 2.1.0 can talk to an iPad, but that does not mean that this HID report error isn't the problem. I think the problem is that when I put both the keyboard AND the mouse reports in, the iPad gets confused - and not getting a proper report map could still well be the problem. I'm attempting to debug this but I would really still like some Nordic Support help to get to the bottom of this report descriptor failure.

[Glen M]

On further testing, I've found that they keyboard portion of this combined keyboard/trackpad product starts working fine when I remove the following configuration options that add in the mouse report - so it seems that the iPad doesn't like my combined keyboard/mouse report:

CONFIG_DESKTOP_HID_REPORT_MOUSE_SUPPORT=y

CONFIG_DESKTOP_HID_MOUSE=y

It seems that the iPad doesn't like something about the combined keyboard/mouse report. I will continue to try to debug, but any help you can provide would be greatly appreciated.

I've also been experimenting with these defines but increasing them beyond what I have here does not help:

CONFIG_BT_HIDS_INPUT_REP_MAX=6
CONFIG_BT_HIDS_OUTPUT_REP_MAX=2
CONFIG_BT_HIDS_FEATURE_REP_MAX=2
CONFIG_BT_HIDS_ATTR_MAX=50

Is there a way to break this up into two separate HID reports?

Thanks,

Glen