HID forward module¶
Use the HID forward module to:
Receive the HID input reports from the peripherals connected over Bluetooth.
Forward the Configuration channel data between the peripherals connected over Bluetooth and the host.
Module events¶
Source Module |
Input Event |
This Module |
Output Event |
Sink Module |
---|---|---|---|---|
|
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
Note
See the Overview: Firmware architecture for more information about the event-based communication in the nRF Desktop application and about how to read this table.
Configuration¶
Complete the following steps to configure the module:
Complete the basic Bluetooth configuration, as described in Bluetooth in nRF Desktop.
Enable and configure the GATT Human Interface Device (HID) Service Client (
CONFIG_BT_HOGP
).Note
Make sure to define the maximum number of supported HID reports (
CONFIG_BT_HOGP_REPORTS_MAX
).Make sure that the
CONFIG_DESKTOP_HID_STATE_ENABLE
option is disabled. The nRF Desktop central does not generate its own HID input reports. It only forwards HID input reports that it receives from the peripherals connected over Bluetooth.The HID forward module is enabled with the
CONFIG_DESKTOP_HID_FORWARD_ENABLE
option. This option is available only if you enable both theCONFIG_BT_CENTRAL
andCONFIG_BT_HOGP
Kconfig options. The module is used on Bluetooth Central to forward the HID reports that are received by the HID service client.
You can set the queued HID input reports limit using the CONFIG_DESKTOP_HID_FORWARD_MAX_ENQUEUED_REPORTS
Kconfig option.
Implementation details¶
This section describes the functioning of the HID forward module.
Interaction with the USB¶
The USB state module can be configured to have one or more instances of the HID-class USB device. If there is more than one instance of the HID-class USB device, this number must match the maximum number of bonded Bluetooth peripheral devices. Each instance of HID-class USB device subscribes to HID reports forwarded by the HID forward module.
The HID forward module has an array of subscribers, one for each HID-class USB device. The possible cases that impact how the host to which the nRF desktop dongle is connected interprets the reports are as follows:
Number of HID-class USB devices is equal to number of bonded peripheral devices. In this case:
Reports from every bonded peripheral will be forwarded to a dedicated HID-class USB device.
The host can distinguish the source of the report.
Only one HID-class USB device is used. In this case:
Reports from all peripherals will be forwarded to a single HID-class USB device.
The host cannot distinguish the source of the report.
When reports are forwarded to the USB state module, each HID-class USB device is treated independently. This means that the HID forward module can concurrently send reports to every available HID-class USB device, if a report from the linked peripheral is available.
Forwarding HID input reports¶
After Bluetooth LE discovery module successfully discovers a connected peripheral, the HID forward module automatically subscribes for every HID input report provided by the peripheral.
The hidc_read()
callback is called when HID input report is received from the connected peripheral.
The received HID input report data is converted to hid_report_event
.
hid_report_event
is submitted and then the HID-class USB device configured by USB state module forwards it to the host.
When a HID report is sent to the host by the HID-class USB device, the HID forward module receives a hid_report_sent_event
with the identifier of this device.
Enqueuing incoming HID input reports¶
The HID forward module forwards only one HID input report to the HID-class USB device at a time.
Another HID input report may be received from a peripheral connected over Bluetooth before the previous one was sent.
In that case, hid_report_event
is enqueued and submitted later.
Up to CONFIG_DESKTOP_HID_FORWARD_MAX_ENQUEUED_REPORTS
reports can be enqueued at a time for each report type and for each connected peripheral.
If there is not enough space to enqueue a new event, the module drops the oldest enqueued event that was received from this peripheral (of the same type).
Upon receiving the hid_report_sent_event
, the HID forward module submits the hid_report_event
enqueued for the peripheral that is associated with the HID-class USB device.
The enqueued report to be sent is chosen by the HID forward module in the round-robin fashion.
The report of the next type will be sent if available.
If not available, the next report type will be checked until a report is found or there is no report in any of the queues.
If there is no hid_report_event
in the queue, the module waits for receiving data from peripherals.
Bluetooth Peripheral disconnection¶
On a peripheral disconnection, nRF Desktop central informs the host that all the pressed keys reported by the peripheral are released. This is done to make sure that user will not observe a problem with a key stuck on peripheral disconnection.
Configuration channel data forwarding¶
The HID forward module forwards the Configuration channel data between the host and the peripherals connected over Bluetooth. The data is exchanged with the peripheral connected over Bluetooth using HID feature report or HID output report.
In contrast to HID configurator for nRF Desktop, the HID forward module does not use configuration channel request to get hardware ID (HW ID) of the peripheral. The peripheral indentification on nRF Desktop central is based on HW ID that is received from Bluetooth LE discovery module when peripheral discovery is completed. The peripheral uses Device description module to provide the HW ID to the nRF Desktop central.
The HID forward module only forwards the configuration channel requests that come from the USB connected host, it does not generate its own requests.
For more details, see Configuration channel documentation.