Repository navigation
Logitech: explain an empty profile list, and set up profiles on a blank PRO X 3 without G HUB - #589
Merged
snekxs merged 4 commits intoOct 6, 2026
Conversation
A Logitech mouse that G HUB has never linked has a blank onboard profile directory, so the profile list is empty and the only message was 'This mouse reported no onboard profiles.' with no hint what to do. Say why and how to fix it: link the mouse in G HUB once, then reload. Profiles appear after that first link (issue OpenMouse-Project#516).
A Logitech mouse G HUB has never linked has an empty profile directory, so the profile list was empty. Offer a Set up profiles button when the list is empty and the mouse has a captured factory image (PRO X 3 SUPERSTRIKE): it writes the factory profiles with profile 1 active and reloads the list. Needs the new initializeBlankOnboardProfiles from @openmouse/protocol, so it waits on the protocol release (issue OpenMouse-Project#516).
…de it It rendered as an unstyled browser button, a large gray block next to the small bordered icon buttons. Reuse .icon-button with a compact text variant that uses theme tokens only.
The Set up profiles button and action were gated on supportsFactoryReset(), which is also true for profile format 7. Format 7 has no captured factory sectors, so initializeBlankOnboardProfiles() always threw "Factory profiles have not been captured for profile format 7" — after the user had already confirmed a flash write. A format-7 mouse with an empty directory is exactly the OpenMouse-Project#516 state, so the dead end was reachable, and the new empty-list message ("Where Set up profiles is shown, OpenMouse can create them itself") was false for those mice. Move the predicate into src/device/logitech-factory.ts and gate on the captured factory directory (factoryDirectoryForFormat returns null for every format and sector size except the captured one), which is what the client itself checks before writing. Reset keeps supportsFactoryReset, which is the right question there because the factory profile sectors are what it needs. Also drop the claim that this is what G HUB does the first time it links a mouse: the captured sequence is G HUB's reset, and it has not been run against a never-linked mouse. Bumps @openmouse/protocol to 0.23.1, which carries the new Logitech API. tsc --noEmit clean, 269/269 tests (3 new), vite build clean.
snekxs
marked this pull request as ready for review
October 6, 2026 00:16
pepperino9900
pushed a commit
to pepperino9900/openmouse
that referenced
this pull request
Oct 6, 2026
Both budgets were effectively exhausted, so the next card, theme or driver change would have tripped npm run size for no reviewable reason: CSS 194157 / 195000 bytes (100%) -> 210000 (92%) JS 2084199 / 2085000 bytes (100%) -> 2150000 (97%) The JS growth is the protocol 0.26.0 device batch: AJAZZ AJ179 PRO (OpenMouse-Project#169), Redragon M690 PRO (OpenMouse-Project#163, wired into the panel by OpenMouse-Project#617), Lamzu Paro Aurora (OpenMouse-Project#172), plus the X11-on-Bridge (OpenMouse-Project#174), PRO X Wireless format 4 (OpenMouse-Project#175) and Logitech onboard-profile (OpenMouse-Project#166/OpenMouse-Project#589) work. Their protocol codecs arrive through bridge-hid's SUPPORTED_HID_FILTERS as well as the controllers. Measured with a clean npm ci against the committed lockfile, after npm run build: CSS 194.2 kB, JS 2,084.2 kB.
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
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.
Refs #516.
A Logitech mouse that G HUB has never linked has a blank onboard profile directory, so OpenMouse showed an empty list and only "This mouse reported no onboard profiles." with no hint what to do.
Note on the cause: it is not G HUB's files. OpenMouse reads profiles from the mouse over HID, and the mouse has none stored until G HUB links it.
What
.icon-buttonwith theme tokens only.Depends on
mouse-protocol#166 (adds
initializeBlankOnboardProfilesand the format 8 factory image). This stays a draft until that is merged and released and the@openmouse/protocolpin is bumped; CI will fail on the missing method until then.Not verified
The setup write has not been run against a truly never-linked X3. It replays G HUB's reset sequence, which was captured on a mouse that already had profiles, and says so in the protocol PR. Ideally the reporter of #516 tries it on a blank mouse once it is released.
Checks
tscis clean against the protocol branch, and the app tests pass (266).