Himy USB keyboard application works on Windows and Linux but not on a MacBook Air with macOS Sierra 10.12.6. So I did step back and tried the combined HID examplenRF5_SDK_16.0.0_98a08e2/examples/peripheral/usbd_hid_composite/hex/usbd_hid_composite_pca10056.hexwith md5sum 6ffe5856a45b765a6ecf10ec0e348cdcsurprise: it does not work eitherwhat I did:flash the example hex file on PCA10056 version 2.0.1connect the board to the MacBook Airresult:mouse works perfectly as expectedkeyboard is visible in the OS settings dialog for keyboardsno reaction at all on button3 (SHIFT) and button4 (letter G)unexpected behaveour of LED3 - the picture below shows the LED timing on an oscilloscope:stable for about 20ms then 4 toggles in row
I look at the code and from this point I'm guessing:the LED might get inverted in APP_USBD_HID_USER_EVT_OUT_REPORT_READYis the OS asking for information?or trying to discover the type of the keyboard by provoking a reaction (which is not delivered by the example code)?I'm aware that the OS does not recognize the type of the keyboard and it asks me to press the button right of LEFT-SHIFT.This button might be 'Z' on an standard US keyboard or the additional "NON-US-KEY" (keycode 100 decimal) on non-US keyboards.The DevKit is not a real keyboard so I can't press this key and I skip this step and set the european keyboard type later manually.But this does not help - the keyboard part of the DevKit example is still stuck.I'm new to USB and HID. And I don't know how to low level debug USB/HID on a Mac.So I tried comparing USB descriptors of the example with a Holtek keyboard which works fine.But I couldn't find a notable difference.Just one detail - it could be a hint or spurious neglectable glitch:when I compared descriptors on Linux I saw an empty (all zeroes) IN report coming from the Holtek keyboard at the beginning.I didn't expect this report and I don't know if I should pay attention to it.question:are you able to reproduce the problem connecting the composite HID example to a Mac?despite searching forums a lot I have no clue yet what to look for.suggestions are welcome - for example: should I dive into USB spec to find if an OS can ask questions to a keyboard and the example does not cover this dialog?
Wireshark can capture USB on a Mac - bad luck - the MacBook Air I have for testing is too old for it to work :-(
I added a lot of NRF_LOG everywhere in the code. To get output I had to add NRF_LOG_DEFAULT_BACKENDS_INIT() in main().
To my surprise hid_kbd_user_ev_handler(APP_USBD_HID_USER_EVT_IN_REPORT_DONE) was constantly called. It felt like an inifinite loop. In the code I could only find one call in app_usbd_hid.c line 428 function endpoint_in_event_handler().
you mentioned that changing vendorID to Apple eliminates the problem. I have no experience in this area but somehow I have to fix this, so I try a hypothesis: with an Apple vendorID the "foreign keyboard identification" process is skipped - even if the keyboard is not in an internal list of known Apple keyboards you cannot ask your customer what keyboard he connected if it comes from Apple too - that would be embarassing ;-)
So the problem might be the keyboard detection process itself which might behave differently. This might lead to a non-reset of a flag or a missing ACK and as a consequence to an infinite repetition of the IN report (?)
Maybe you can use Wireshark on a Mac or you have a hint what I should look for. I'll try to dive deeper into the code with a fresh mind tomorrow.
I have also seen that the hid_kbd_user_ev_handler() is called repeatedly. We believe that this issue is likely due to a missing feature at the application level of the usbd_hid_composite example, but we are not sure what MacOS expects the application to do. I will try to get some insight into this, hopefully, this week, but I cannot promise anything. Please let me know what you find during your investigation.
thanks - Windows uses a different approach at startup.MacOS probes just 8 bytes of Device Descriptor to discover the buffer size, then restarts reading Device Descriptor with buffer size 64.
Windows fetches the Device Descriptor with 64 byte and then applies RESET, Set Address and re-fetches the Device Descriptor.
Interesting STALLED transfer at 3.784.
@ 3.783: get Serial Number string in ENGLISH_US right away without checking for supported languages.
@ 3.862: asking for only 4 bytes of string ???Is this a check if the string is delivered but the content is not of interest?
daily business is calling - I continue later
comparing Windows vs MacOS is interesting, but it hasn't really helped me (yet).
In the code I didn't find evidence that STALLED would have interesting effects.
I'm still surprised that SDK16 with vendor Nordic produces HID IN periodic reports. I see no stimulus and no reason why they should be sent.
summary: no real progress on my side
Thanks for the update. I do not have any updates from our side yet, unfortunately.
Einar is on vacation, so I am taking over the case.
Could you please try to insert a new line in app_usbd_hid_kbd.c, function hid_kbd_on_idle(), just below NRF_DRV_USBD_TRANSFER_IN(...), around line 543:
This inserted function updates the USB keyboard buffer to make sure that each "idle" transfer reflects the actual keyboard state.
Please let me know the result.
you made my day!Both the original example and my own application work on the MacBook I have for testing.I'll try other Apple machines as soon as possible but for now - GREAT!
have as much fun as I do :-)Peter