Questions and answers

A universal language for wearable controllers. It carries a controller's input to the app that should receive it.

Gestural Interface Device. The gestural devices being rings, clickers, glasses controllers, and the like.

With HID, the operating system takes the input and gives it to whatever app is in front. Your app never sees the raw signals. GID gives them a direct path to a specific app.

No. HID still handles keyboards and mice. GID handles wearable controllers, whose input the operating system currently swallows.

The operating system treats it as a keyboard or mouse and routes it to the focused app. The raw input never reaches you. GID delivers it to your app directly.

No, by design. That is what lets its input reach a specific app instead of being intercepted by the operating system.

Every message carries an address naming the target app. One controller can drive any of several apps.

No. It carries input from any wearable controller. Specific gesture sets are extensions, not the core.

The controller describes itself: what it is and what it sends. The host reads that description. Same idea as HID.

Nothing breaks. The format is versioned, and unknown fields are ignored rather than rejected.

Yes. The channel is two-way: change modes, confirm an action, trigger haptics.

No. GID is not a display driver. It never sends pixels or draws anything. It delivers input, and the app decides what to show. Input can change the display, but only because the app reacts to it.

About what HID takes. The spec defines a small set of generic message formats, and you do not write your own parser for them. There is one reference implementation, a small portable C library (a .c and a .h), that builds and reads GID messages. You fork that same code into your firmware and into your app, so every implementation frames messages identically. On top of it you declare your device's descriptor and any vendor-specific messages.

Every message reserves space for vendor-specific signals, with no permission needed. The goal is that GID defines enough standard actions that you rarely need it, but the room is always there.

You can claim your own extension space without asking anyone. Only the shared core list is reviewed.

Bluetooth LE first. The format is transport independent, so other links can be added later.

That is a hard requirement. We are verifying each transport keeps working while the phone is locked.

The phone is the bridge between the controller and your glasses. GID standardizes that bridge instead of every vendor rebuilding it.

Plain input is open. Anything that controls a device or changes state requires an encrypted, authorized setup first. Deeper security hardening is out of scope for v0.

It uses standard Bluetooth security instead of inventing its own. The trust-setup details are still being finalized.

Not yet. It is in active design. The foundations are settled and a draft spec is next, but nothing is frozen.

PeKe Labs stewards it as an open standard. PeKe steers v0, and opens it up as it matures.