Skip to content

Hardware specifications

Start with the hardware baseline that affects plugin layout, interaction and resource use, then consult the relevant APIs. These values come from the current reference firmware and public SDK. For other models or versions, rely on runtime queries and physical-device testing.

Four things to know before designing#

  • Canvas size

    600 × 350 px

    The current logical plugin canvas. The origin is at the top left; X increases to the right and Y increases downward. Code must still query the actual width and height.

  • Pixels

    4-bit grayscale

    The public framebuffer uses GRAY_4 encoding. Design graphics and states for grayscale rendering.

  • Display controls

    Brightness levels 1–10

    Display distance and height each have levels 0–8. These levels are not physical brightness, centimeters or pixels.

  • Connection

    The App runs plugins via Bluetooth

    The LAN carries the ZIP from the computer to the phone. The App then transfers the GMP over Bluetooth for execution on the glasses.

Display and optical controls#

Coordinates, canvas, and green intensityThe reference logical canvas is 600 × 350, with its origin at the top left, X to the right, and Y downward. GRAY_4 encodes 4-bit intensity, two pixels per byte. The hardware displays 16 green intensity levels, not black-and-white grayscale. Query actual dimensions and follow the surface stride and tile bounds.MEMOMIND / DISPLAY GEOMETRYCoordinates, canvas, and green intensity600 px · width350 px · height(0, 0) OriginX →Y ↓Illustrative contentGRAY_4 · 16 green levels0: no light; 15: brightest pure green. This ramp illustrates intensity, not a measured response curve.4 bits per pixel; 2 pixels per byte.Follow actual surface.stride, y, and height when drawingdirectly. Do not treat the full screen size as each tile'ssize.This is a logical canvas, not an optical field-of-view or safe-area specification. Usedimensions returned by display_get_info.
Coordinates, canvas, and green intensityThe reference logical canvas is 600 × 350, with its origin at the top left, X to the right, and Y downward. GRAY_4 encodes 4-bit intensity, two pixels per byte. The hardware displays 16 green intensity levels, not black-and-white grayscale. Query actual dimensions and follow the surface stride and tile bounds.MEMOMIND / DISPLAY GEOMETRYCoordinates, canvas, andgreen intensity600 px · width350 px · height(0, 0) OriginX →Y ↓Illustrative contentGRAY_4 · 16 green levels0: no light; 15: brightest puregreen. This ramp illustratesintensity, not a measured responsecurve.4 bits per pixel; 2 pixels perbyte.Follow actual surface.stride, y,and height when drawingdirectly. Do not treat the fullscreen size as each tile's size.This is a logical canvas, not anoptical field-of-view or safe-areaspecification. Use dimensionsreturned by display_get_info.
Design with logical coordinates and 16 green intensity levels, then lay out using dimensions returned by the device.
ItemCurrent API or rangeUsage
Logical canvasThe current reference firmware and Studio use a 600 × 350 px logical canvas. Query width / height with display_get_info.Lay out the UI using the returned dimensions. Do not treat this default as a permanent specification for every device model.
Pixel formatGRAY_4: 4-bit intensity encoding, displayed as 16 green intensity levels on the hardware, with two pixels per byte.Direct drawing must respect the surface stride, y and height. Adapt color images to the public image pipeline first.
Display count and refresh informationThe current firmware Host reports 1 logical display and a nominal refresh rate of 30 Hz.Query logical_display_count and refresh_hz. Logical display count does not specify monocular or binocular optics, and a nominal refresh rate does not guarantee that your application sustains 30 FPS.
Brightnessdisplay_control.brightness_get / brightness_set use enumerated levels 1–10.Levels are neither percentages nor physical brightness units. Adjust them only when needed for a user action, and verify restoration after stopping.
Display distance and heightdistance_get / distance_set and height_get / height_set each use enumerated levels 0–8.Levels are not centimeters or pixel offsets. Read the current value first, then set a value from the public enumeration.
Display power and automatic brightnessscreen_is_on、screen_turn_on、auto_brightness_block。These controls affect the actual viewing experience. Verify them with Display Control Lab first. The Host releases the automatic-brightness block when the plugin stops.
Fonts and measurementfont_default, font_large and the text-measurement APIs in the LVGL table.Reuse Host fonts and measure actual glyphs. Do not infer from a reference design that arbitrary font sizes are available.

Input, IMU and device state#

CapabilityCurrently exposed functionalityImportant considerations
Main buttonPRIMARY + SINGLE / DOUBLE / LONG / VERY_LONG / RELEASE。Distinguish the button identifier from the action. Ignore unrecognized combinations.
Navigation InputDirectional input, page navigation, scrolling, BACK and HOME use TRIGGER.Repeatable navigation keys trigger repeatedly. Verify on the physical device whether the actual input hardware produces these events.
Head gesturesIMU_GESTURE events include public enum values for nodding, looking up, looking down, shaking the head, turning left/right and other supported gestures.Enable the corresponding mode before handling events. Verify thresholds and jitter while actually wearing the glasses.
Raw IMUimu_enable(RAW)、imu_read；accel_raw[3]、gyro_raw[3]、temperature_raw、pitch_degrees。The first three types of raw values are not converted to physical units by this API. pitch_degrees is an integer angle. EBUSY means no sample is currently available.
Battery and chargingbattery_percent returns 0 – 100; battery_charging returns the boolean value.These describe the current device state, not an estimate of remaining runtime.
Languagelocale_get returns the language tag.Plugins maintain their own translations. The firmware does not translate application copy for them.
Wear statehost->wearing() returns bool and requires GM_PLUGIN_CAP_DEVICE_STATE.Verify the results with the glasses worn and removed on a physical device. This query does not introduce a new Web device event.

Audio, connections and data paths#

CapabilityCurrent integration methodDevelopment implications
Plugin messagingGMP uses host->bt_send; Web uses gm.plugin.sendMessage / onMessage, with forwarding through the App.Business commands need their own result acknowledgments, timeouts and recovery after disconnection. Do not use the computer LAN address for direct networking from the glasses.
Audio capture and recordingPhoneSDK provides openCapture / openRecording. The phone host manages the actual input source and authorization.The GMP core API table does not directly expose Mic / Speaker PCM or arbitrary microphone-array selection.
Audio playbackWeb uses media playback capabilities and declares audio.playback.Verify the actual output route and system state on the target phone and glasses. Provide readable text alongside important results.
Device StatusThe public Host API can query battery level, charging, wear state and language. Raw IMU readings have separate data fields.wearing() returns the current wear-detection result. temperature_raw does not directly represent degrees Celsius or the device thermal state.

Runtime resources and available APIs#

  • GMP uses the memory and drawing services provided by the Host. The firmware owns the graphics tile buffers. Standard UI reuses the Host LVGL instance rather than creating another engine and full-screen buffer.
  • GMP code and read-only constants execute from the Flash cache. data/BSS and dynamic allocations still occupy RAM; static variables are not persistent storage. Use the appropriate phone-side facility for persistent settings or user files.
  • Package size, image memory and Web file limits are build and runtime constraints. A small compressed ZIP does not guarantee that its GMP or MMPKG can run.
  • The current public APIs provide no entry points for arbitrary Flash access, firmware upgrades, factory calibration, the glasses camera or system context-menu registration.

What you must verify while wearing the glasses#

Verify readability, optical brightness, input response, IMU noise, sustained refresh and power consumption on the target hardware. These SDK APIs do not specify weight, field of view, virtual-image distance or frame dimensions. Do not derive them from the simulator or logical canvas.

Reference files in the toolkit#

  • GlassSDK/include/gm_plugin.h
  • GlassSDK/include/gm_plugin_lvgl_api.h
  • GlassSDK/docs/GRAPHICS.md
  • PhoneSDK/packages/web-sdk/src/index.d.ts
  • PhoneSDK/examples/display-control-lab/README.md
  • PhoneSDK/examples/audio-capture-lab/README.md