RFC: Add HOGP (HID over GATT Profile) 1.1 service with ULL HID support

[chengkai15]

Problem Description

Zephyr currently lacks a proper reusable HOGP (HID over GATT Profile) service implementation. The only HID-related code is the samples/bluetooth/peripheral_hids/ sample, which directly constructs GATT attributes inline — not reusable across products.

Meanwhile, the Bluetooth SIG has adopted HOGP 1.1 (https://www.bluetooth.com/specifications/specs/hid-over-gatt-profile/ (https://www.bluetooth.com/specifications/specs/hid-over-gatt-profile/)), which extends HOGP 1.0 with support for HID reports over LE Isochronous Channels (HID ISO). Combined with BT 6.2 Shorter Connection Intervals (SCI), this enables Ultra-Low Latency (ULL) HID — targeting ≤1ms latency and 1kHz+ report rates for gaming peripherals, VR controllers, and professional input devices.

Key gaps in Zephyr today:

1. No subsys/bluetooth/services/hogp/ module (unlike BAS, DIS, HRS, OTS which all have proper service implementations)
2. No HOGP Host (GATT client) role — needed for centrals that connect to HID peripherals
3. No HID ISO Service support (HOGP 1.1 feature for reports over CIS)
4. No SCI host-side plumbing (new HCI commands from BT 6.2: LE_Conn_Rate_Request, LE_Set_Default_Rate_Params, LE_Read_All_Remote_Features, LE_Read_Min_Supported_Conn_Interval)

Without these, Zephyr-based products cannot compete in the ULL HID market that is rapidly growing (gaming mice, keyboards, VR/AR controllers).

Proposed Change (Summary)

Add a complete HOGP 1.1 implementation under subsys/bluetooth/services/hogp/ with:

• HOGP Device role (GATT server): HID Service with Report Map, Input/Output/Feature Reports, HID Information, Protocol Mode
• HOGP Host role (GATT client): Service discovery state machine, report subscription, Get/Set Report operations
• HID ISO Service (optional, Kconfig-gated): Send/receive HID reports over LE Connected Isochronous Streams (CIS) for ultra-low latency
• SCI host support (optional, Kconfig-gated): BT 6.2 Shorter Connection Intervals HCI command/event handling

All new features are gated behind Kconfig options (CONFIG_BT_HOGP_DEVICE, CONFIG_BT_HOGP_HOST, CONFIG_BT_HOGP_DEVICE_ISO, CONFIG_BT_HOGP_HOST_ISO, CONFIG_BT_SHORTER_CONNECTION_INTERVALS).

Proposed Change (Detailed)

1. Directory Structure

subsys/bluetooth/services/hogp/
├── Kconfig.hogp # Kconfig options
├── CMakeLists.txt # Build rules
├── hogp_device.c # HOGP Device (GATT server)
├── hogp_host.c # HOGP Host (GATT client)
└── hogp_internal.h # Shared internal definitions

include/zephyr/bluetooth/services/
├── hogp_device.h # Public HOGP Device API
└── hogp_host.h # Public HOGP Host API

2. HOGP Device Role (GATT Server)

Implements HID Service (HIDS) per HOGP 1.1 §3:

• Report Map characteristic (read-only)
• HID Information characteristic
• HID Control Point characteristic
• Protocol Mode characteristic
• Input/Output/Feature Report characteristics with Report Reference descriptors
• Per-connection CCC tracking for notifications
• Boot Protocol support (optional, Kconfig-gated)

Public API:

int bt_hogp_device_register(const struct bt_hogp_device_param *param);
int bt_hogp_device_send_input_report(struct bt_conn *conn, uint8_t report_id,
const uint8_t *data, uint16_t len);
int bt_hogp_device_notify_battery(struct bt_conn *conn, uint8_t level);

3. HOGP Host Role (GATT Client)

Implements HOGP Host per HOGP 1.1 §4:

• HID Service discovery state machine (discover services → characteristics → descriptors → read report map → subscribe)
• Multiple HID service instance support
• Battery Service (BAS) discovery and subscription
• Get Report / Set Report operations
• Protocol Mode read/write

Public API:

int bt_hogp_host_connect(struct bt_conn *conn, const struct bt_hogp_host_cb *cb);
int bt_hogp_host_disconnect(struct bt_conn *conn);
int bt_hogp_host_get_report(struct bt_conn *conn, uint8_t report_id,
uint8_t report_type, uint8_t *buf, uint16_t buf_len);
int bt_hogp_host_set_report(struct bt_conn *conn, uint8_t report_id,
uint8_t report_type, const uint8_t *data, uint16_t len);

4. HID ISO Service (HOGP 1.1 Extension)

When CONFIG_BT_HOGP_DEVICE_ISO=y / CONFIG_BT_HOGP_HOST_ISO=y:

• HID ISO Service GATT characteristics (LE HID Operation Mode, ISO Parameters)
• CIG/CIS establishment for HID report transport
• ISO packet format: [length][seq_num][report_id][payload]
• Hybrid mode: reports sent over both GATT notifications and ISO simultaneously during transition
• Fallback to GATT-only if ISO setup fails

5. SCI Host Support (BT 6.2)

When CONFIG_BT_SHORTER_CONNECTION_INTERVALS=y:

• New HCI command definitions in hci_types.h:

  • LE_Read_All_Remote_Features (opcode 0x2088)
  • LE_Connection_Rate_Request (opcode 0x209F)
  • LE_Set_Default_Rate_Params (opcode 0x20A1)
  • LE_Read_Min_Supported_Conn_Interval (opcode 0x20A3)

• Extended LE feature pages (page 0 + page 1) storage in struct bt_conn

• conn_rate_changed callback in struct bt_conn_cb

• SCI connection interval units: 0.125ms (vs standard 1.25ms)

6. Kconfig Hierarchy

CONFIG_BT_HOGP_DEVICE (bool, depends on BT_PERIPHERAL)
CONFIG_BT_HOGP_DEVICE_MAX_CONNECTIONS (int, default 3)
CONFIG_BT_HOGP_DEVICE_MAX_REPORTS (int, default 8)
CONFIG_BT_HOGP_DEVICE_ISO (bool, depends on BT_ISO_CENTRAL or BT_ISO_PERIPHERAL)

CONFIG_BT_HOGP_HOST (bool, depends on BT_CENTRAL, BT_GATT_CLIENT)
CONFIG_BT_HOGP_HOST_MAX_CONNECTIONS (int, default 3)
CONFIG_BT_HOGP_HOST_ISO (bool, depends on BT_ISO_CENTRAL)

CONFIG_BT_SHORTER_CONNECTION_INTERVALS (bool, depends on BT_CONN)
CONFIG_BT_LE_EXTENDED_FEAT_SET (bool)

7. Reference Implementation

A working implementation exists at: open-vela/external_zblue#226 (open-vela/external_zblue#226)

This RFC proposes to upstream a cleaned-up version that:

• Removes vendor-specific workarounds (BES controller hacks)
• Removes multi-controller extensions (not applicable to upstream Zephyr)
• Fixes known issues identified in code review (per-connection CCC, memory leak, build issues)
• Adds proper bsim tests and documentation

Dependencies

• Bluetooth Host (subsys/bluetooth/host/): SCI support adds new HCI event handlers in hci_core.c and new APIs in conn.c. These are additive and gated behind Kconfig.
• ISO subsystem (subsys/bluetooth/host/iso.c): HID ISO mode uses existing bt_iso_chan_connect() API. No changes to ISO core needed.
• GATT subsystem: Uses existing bt_gatt_service_register(), bt_gatt_notify(), bt_gatt_discover(), bt_gatt_subscribe() APIs. No changes needed.
• Controller: SCI requires controller support for BT 6.2 commands. The host-side code gracefully degrades if controller doesn't support SCI (checked via supported commands bitmask).
• Samples: New samples/bluetooth/peripheral_hogp/ and samples/bluetooth/central_hogp/ to demonstrate usage.
• Documentation: New pages under doc/connectivity/bluetooth/ for HOGP service API.
• Tests: bsim-based integration tests under tests/bsim/bluetooth/host/hogp/.

Concerns and Unresolved Questions

1. SCI spec maturity: BT 6.2 SCI is relatively new. Controller support is limited (currently only a few vendors). Should SCI be in a separate RFC/PR series, or bundled with HOGP?
2. HID ISO Service UUID assignment: The HOGP 1.1 spec defines the HID ISO Service, but some UUIDs may still be pending final SIG assignment. Need to confirm assigned numbers are finalized.
3. Interaction with nRF Connect SDK: Nordic has their own HID service in NCS (subsys/bluetooth/services/hids/). How to coordinate so upstream HOGP doesn't conflict with NCS's existing implementation?
4. Boot Protocol support: HOGP 1.0 mandates Boot Protocol for keyboards/mice. Should this be mandatory or optional (Kconfig-gated) in the upstream implementation?
5. PTS test coverage: HOGP 1.1 has a new Test Suite. What level of PTS test pass rate is expected before merging?
6. Security model for HID ISO Service: HOGP 1.1 spec says HID ISO Service characteristics have "Security Permissions = None", but this creates a mixed security model with HIDS (which requires encryption). Is
   this acceptable, or should we enforce minimum security?

Alternatives Considered

1. Keep HID at sample level only (status quo)

   • Pros: No maintenance burden
   • Cons: Every product re-implements HID service; no code reuse; no path to ULL HID
   • Rejected because: Inconsistent with how other SIG profiles (BAS, DIS, HRS, OTS, IAS) are handled in Zephyr

2. Implement only HOGP 1.0 (GATT-only, no ISO)
   - Pros: Simpler, no ISO dependency
   - Cons: Misses the primary value proposition of HOGP 1.1 (ULL HID); would need another RFC later for ISO
   - Considered as a phased approach: HOGP 1.0 first, then 1.1 extension

3. Implement HOGP in application layer / external module
   - Pros: No upstream review burden
   - Cons: Fragmentation; each vendor implements differently; no interop testing
   - Rejected because: HOGP is a SIG-adopted profile that belongs in the stack

4. Wait for other vendors to implement first
   - Pros: Less risk
   - Cons: Zephyr falls behind; gaming/VR market moves fast
   - Rejected because: We have a working implementation ready to upstream

Chosen approach: Full HOGP 1.1 implementation, submitted as a phased PR series (HOGP 1.0 basics first, then ISO extension, then SCI), allowing incremental review and merge.

[chengkai15]

We'd like to hear different perspectives from the community — whether it's about the overall direction, API design, phasing strategy, or any concerns.

thanks for any feedback.

[Thalley]

I don't see any mention of ISO in HID Profile 1.1.2; can you elaborate on how that would be used and where it's defined as standard? I don't think Zephyr should implement anything non-standard like that (or at best, as a sample).

My main concern about adding it / moving it from a sample to services (which doesn't really match either, since it's a profile), is who will maintain and test it?

What do we gain from moving/adding it as a in-tree implementation rather than a sample?

[chengkai15]

Thanks for the feedback @Thalley. Let me address each point:

1. ISO in HID Profile — where is it defined?

You're right that HID Profile 1.1.2 (BR/EDR) does not mention ISO. The ISO transport for HID is defined in HOGP 1.1 (HID over GATT Profile), which is a separate adopted specification:

• Spec: https://www.bluetooth.com/specifications/specs/hid-over-gatt-profile/
• Specifically: HOGP 1.1 Section 3.3 "HID ISO Service" defines a new GATT service that enables HID report transport over LE Connected Isochronous Streams (CIS).
• The associated service spec is "HID Service 1.1" (HIDS 1.1), which adds the LE HID Operation Mode and ISO Parameters characteristics.

refer to : https://www.bluetooth.com/specifications/specs/html/?src=hogp-v1-1_1755558551/HOGP_v1.1/out/en/index-en.html#UUID-caad6d7d-a2fa-adaf-ac0b-2196b6bc02d5

This is fully standard — adopted by the Bluetooth SIG, with assigned UUIDs and a PTS test suite. It is NOT a proprietary extension.

I apologize for the confusion in my RFC — I should have been clearer that the "ULL HID" part refers to HOGP 1.1 (LE/GATT profile), not HID Profile 1.1.2 (BR/EDR). These are two separate specs. I'll update the RFC description to clarify.

2. Who will maintain and test it?

I (Xiaomi) commit to:

• Maintaining the HOGP implementation (both Device and Host roles)
• Running PTS qualification tests (we have a PTS dongle and license)
• Providing bsim-based CI tests for automated regression
• Responding to bug reports and review requests

We ship HOGP on production devices (gaming accessories) and have strong incentive to keep it working. I'm happy to be listed as maintainer in MAINTAINERS.yml for the hogp/ subtree.

3. What do we gain from in-tree vs sample?

Aspect	Sample	In-tree service
Code reuse	Copy-paste per product	Single implementation
Multi-connection CCC	Each sample re-invents	Handled correctly once
Boot Protocol	Often skipped	Properly implemented
Host (client) role	Not in any sample	Needed for centrals
Interop testing	None	bsim CI catches regressions
API stability	None (sample = no API contract)	Versioned public API

The existing peripheral_hids sample is ~400 lines of inline GATT attribute construction with no abstraction. Every product using it copies and modifies it, leading to divergent implementations with different bugs. BAS, DIS, HRS, OTS, IAS all graduated from samples to services for the same reason.

Revised proposal (phased)

Given your concerns, I'd like to propose a narrower Phase 1:

Phase 1 (this RFC): HOGP 1.0 Device + Host, GATT-only, no ISO

• Standard HOGP as defined in the adopted spec
• Equivalent to what NCS has in subsys/bluetooth/services/hids/
• No new HCI commands, no ISO dependency
• bsim tests + PTS results included in PR

Phase 2 (separate RFC): HID ISO Service (HOGP 1.1 extension)

• Only after Phase 1 is merged and stable
• Depends on ISO subsystem maturity

Phase 3 (separate RFC): SCI host support (BT 6.2)

• Independent of HOGP, useful for other LE use cases too

Would this phased approach address your concerns? Happy to start with a Phase 1 PR for review.