Windows 8.1 repeated key event

[Ignacio Lopez]

I have an issue with my keyboard working with the windows suface (on windows 8.1). Occasionally, the last character sent is repeated several times instead of one. I do not have the same isue with the ipad (iOS 7.0.3). Therefore, I was thinking if may be any problem with the USB HID events. This is how I am sending and clearing each key stroke:

static uint8_t m_sample_key_release_pattern[8] =                /**< Key pattern to be sent to simulate releasing keys. */
{ 
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00,
    0x00
};

Sending the event an clearing code. The ASCII character goes on the 3rd byte of an 8 byte array (packet->keyboard_keys).

// Code
err_code = ble_hids_inp_rep_send(&s_hids,
            INPUT_REPORT_KEYS_INDEX,
            packet_size,
            (uint8_t*)packet->keyboard_keys);  
ASSERT(packet_size == 8);
ASSERT(packet->keyboard_keys != 0);
// ADD
if (err_code == NRF_SUCCESS)
{
   err_code = ble_hids_inp_rep_send(&s_hids,
            INPUT_REPORT_KEYS_INDEX,
            packet_size,
            m_sample_key_release_pattern);
}

Please let me know if you need more info.

Thanks for your help!

[Ole Morten]

The softdevice have a limited number of buffers available, and if you try to send a packet when these buffers are full, ble_gatts_hvx() will return the BLE_ERROR_NO_TX_BUFFERS_AVAILABLE error.

Could it be that in your case, there is only room for the key press packet in the buffer, but the release is never queued, so that the release is only sent after then next press or release? If so, I'd suggest that you keep track of the numbers of buffers available. A strategy for this is proposed in this document. By doing this, you can know before trying to send the press whether there will also be room for the release, and if not, you can wait with sending the press.