Repository navigation
Conversation
…#1) A host classifies a BLE peripheral from its advertising data. Registering the HID service on the GATT server alone left the advertisement bare, so Android bound no HID profile to the watch ("No profiles"), never attached an input device, and the key reports had no consumer. Also make keyCode() fall back to the default usage code when a name is missing from kb.KEY, instead of returning undefined and letting kb.tap() throw inside safeCall. Bump to 0.02 so the app loader offers the update. Co-authored-by: agent-miku <74595+agent-miku@noreply.localhost>
…ID errors
The glasses' launcher moves through its app grid with Left/Right and only uses
Up/Down inside vertical lists, so swipes now send the key that matches the
configured axis instead of always sending Up/Down.
Double tap cannot be sent as a keyboard report: no keyboard usage reaches
KEYCODE_BACK. The app now supplies its own composite HID descriptor (report 1
keyboard, report 2 consumer control with AC Back / AC Home), which is the only
HID way to produce a real Back. The keyboard collection carries five keys because
a Bangle.js 2 input report is capped at 8 bytes and the report id counts towards
that length.
HID send failures ("BLE HID not enabled", "Not connected", "report too long") are
now shown on the watch, with "HID OFF" when the service was never registered,
instead of being swallowed.
Bump to 0.03.
- swipe direction is the dominant drag component: horizontal -> Left/Right, vertical -> Up/Down, all four directions live with no setting - track the last in-drag position because the release drag event can carry no usable x/y - remove the axis/invert settings screen, stored config and the double-press BTN opener (their only rows were the removed toggles)
Author
|
Closing - this was opened in error; the work is being tracked on the fork (hoonsubin/BangleApps) for on-device testing first. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Reworks swipe handling in
rokidcontroller(v0.04):|dx|vs|dy|) maps toLeft/Right(horizontal) orDown/Up(vertical). All four directions work at all times.dragevent can arrive without usablex/y, which silently swallowed swipes.rokidremote.jsonconfig, and the double-press-BTN opener are gone (their only rows were the removed toggles). BTN1 is now hold-only (Confirm +2TAP).Why
With the previous configured-axis approach, horizontal swipes were never registered when the app was in the default vertical mode, so the glasses' launcher (which moves through its app grid with Left/Right) could not be driven. The on-watch mapping now matches the Rokid navigation contract directly.
Testing
node --check app.jspasses;metadata.jsonparses.