01 The case
Why GID exists
HID is one of the most successful standards ever shipped. GID is not a replacement for it - it is the part HID never had a reason to define.
02 The gap
Everyone wants to own the OS. Nobody agreed on the I/O.
Wearable computing is the next platform, and every large player knows it. They are racing to own the operating system for glasses and headsets, each behind its own walls, its own store, its own SDK. The incentive is to lock developers in, not to interoperate.
But the layer underneath got skipped. There is still no shared way for a controller to even talk to an app. HID looks like it should fill that role, except HID input belongs to the operating system: it reads the device, then hands the input to whichever app is in front. That is fine for a keyboard. It breaks for a wearable controller, whose signals an app developer would love to build on but can never receive directly.
So every glasses maker ships its own controller, its own protocol, and its own SDK, and any developer who wants to support more than one has to integrate all of them. There is no build-once. There is build N times, for N walled gardens.
That order is backwards. You do not get to claim the operating-system layer before the industry agrees on basic input and output. Shared I/O is the floor everything else stands on. HID proved it on the PC: agree on input first, and a thousand devices just work, on any OS. GID is that floor for wearables. One language for controller input, so a developer integrates once and any compliant device works.
03 Side by side
HID and GID, point for point
GID keeps everything HID got right and adds one new idea: input can be sent to a specific app.
| HID | GID | |
|---|---|---|
| Self-describing devices | Yes - report descriptors | Yes - GID descriptors, HID-inspired |
| No per-device driver | Yes | Yes |
| Where the input goes | Whichever app is in front | A specific app you choose (e.g. on your glasses) |
| Can an app use the raw input | No - the system takes it first | Yes - sent straight to the app. The reason GID exists |
| Transport | USB, Bluetooth HID | BLE GATT first; the envelope is transport-independent |
| Portability across vendors | High | The goal - replaces bespoke per-vendor BLE channels |
04 Restraint
HID is the template - and the ceiling
GID owes its core idea to HID, and it owes HID a debt of discipline too. HID is not very complicated, and that is treated as a feature. HID is GID's complexity ceiling, not just its ancestor. The standard defaults to HID's level of complexity and goes beyond it only where addressing and the host/display split genuinely demand it.
In scope (v0)
- A self-describing model for wearable controllers, so a host knows what a device is without a custom driver.
- A way to aim input at a specific app, instead of letting the system take it.
- A wire envelope, versioning, and an extension mechanism built for forward compatibility.
- A first transport binding over BLE GATT.
- A mandatory-to-implement core and a conformance definition.
Out of scope (v0)
- Rendering or output to the HUD. GID is input.
- Replacing HID where HID already works - keyboards and mice on the host.
- A full security and identity framework beyond a stated v0 baseline.
- Locking specific gesture vocabularies as normative. Those are extensions.