HOGP inputmap reference

Download an editable five-button template#

This example maps Page 0x000C Usage 0x0042, 0x0043, 0x0044, 0x0045, and 0x0041 to up, down, left, right, and confirm respectively, matching the sample remote's captured format. These are not universal ring/remote encodings. Replace them using your Report Map and captured values. Omitting application / rid leaves those fields unrestricted.

{
  "version": 1,
  "rules": [
    {
      "type": "usage_key",
      "page": 12,
      "usage": 66,
      "key": 0
    },
    {
      "type": "usage_key",
      "page": 12,
      "usage": 67,
      "key": 1
    },
    {
      "type": "usage_key",
      "page": 12,
      "usage": 68,
      "key": 2
    },
    {
      "type": "usage_key",
      "page": 12,
      "usage": 69,
      "key": 3
    },
    {
      "type": "usage_key",
      "page": 12,
      "usage": 65,
      "key": 4
    }
  ]
}

• Download hogp-five-key-example.json
• Go back to App connection and import steps

Match HID input on the left; choose glasses output on the right#

Six rule types: choose based on actual reports#

Each block below is a complete single-rule file. Input values illustrate structure and must be replaced with real device data. Combine rules in one rules array and import once; importing separate files successively replaces previous tables.

{
  "version": 1,
  "rules": [{
    "type": "value_match", "page": 65280, "usage": 1,
    "values": [{"value": 1, "key": 4}, {"value": 2, "key": 58}]
  }]
}

{
  "version": 1,
  "rules": [{
    "type": "rel_axis", "page": 1, "usage": 56,
    "positive": 56, "negative": 57
  }]
}

{
  "version": 1,
  "rules": [{
    "type": "abs_axis_to_key", "page": 1, "usage": 48,
    "deadzone": 300, "threshold": 500,
    "positive": 3, "negative": 2
  }]
}

{
  "version": 1,
  "rules": [{
    "type": "abs_region", "axis": "x",
    "tip": {"page": 13, "usage": 66},
    "x": {"page": 1, "usage": 48},
    "y": {"page": 1, "usage": 49},
    "regions": [
      {"min": 0, "max": 332, "key": 2},
      {"min": 333, "max": 665, "key": 4},
      {"min": 666, "max": 999, "key": 3}
    ]
  }]
}

{
  "version": 1,
  "rules": [{
    "type": "touch_gesture",
    "tip": {"page": 13, "usage": 66},
    "x": {"page": 1, "usage": 48},
    "y": {"page": 1, "usage": 49},
    "map": {
      "tap": 4, "swipe_up": 0, "swipe_down": 1,
      "swipe_left": 2, "swipe_right": 3
    }
  }]
}

Output IDs available for selection and import in the current App#

Short press, long press, double-click and Ignore#

• Map an ordinary confirm button to SELECT(4), with stable press and release reports. The glasses distinguish short and long presses by duration, not report repetition count. The foreground application determines final behavior.
• DOUBLE(58) represents a double-click action already distinguished by the device, using a separate Usage or a different value under one Usage. This mapping does not automatically combine two identical short-press reports into a double click.
• The “Ignore” dropdown omits the ordinary recorded rule; uncovered input may still match firmware defaults. usage_key with key 65535 also skips the entry rather than forcibly disabling input. Advanced-rule output slots set to 65535 dispatch no action for that slot. Verify the specific rule on the target device.
• Explicitly list desired axis and gesture outputs instead of depending on version-specific defaults. scroll_up / scroll_down support touch_gesture scrolling. Choose either regions or trajectories for the same input.

Capacity, validation and saving#

The App queries glasses capabilities on page entry; limits may vary by release. Save the results and matching version information during initial integration. Valid JSON is deliverable only after App validation, glasses confirmation, and physical-device testing.

The complete mapping table is validated, replaced, and saved with the bound device. Unpairing clears it. Use the App's “Clear mapping” to restore defaults; file import currently rejects an empty rules array.

How mapped values reach a GMP plugin#

After the glasses decode and map accessory reports, the Host converts supported system buttons into GM_PLUGIN_EVENT_BUTTON. Read event->data.button.button and action in your existing on_event callback. Input adaptation occurs on the glasses; the plugin does not receive or parse inputmap JSON.

• Glasses hardware API: input-event fields and usage
• Run GM 2048 to verify all four directions

Final checks before delivery#

1. Confirm JSON inputs come from the current accessory firmware's actual Report Map/reports. Document the physical button or gesture for each rule; do not reuse another model's values blindly.
2. Wear the glasses, import in the App, and wait for success. Test trigger, release, and retrigger for every rule. With multiple Reports, verify that inputs do not activate the wrong buttons.
3. Test both the target system UI and GMP plugin. An available button event does not mean every foreground application supports the action.
4. Verify reconnection and reboot recovery. Keep validated JSON and version information. Retest after descriptor or action-encoding changes; updating the product description alone is insufficient.

• Integration steps, considerations, and troubleshooting