Skip to content

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 into
OpenMouse-Project:mainfrom
onyxhq-dev:fix/logitech-empty-profiles-guidance
Oct 6, 2026
Merged

snekxs merged 4 commits into
OpenMouse-Project:mainfrom
onyxhq-dev:fix/logitech-empty-profiles-guidance

Conversation

@onyxhq-dev

Copy link
Copy Markdown
Contributor

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

  • Explains the empty state. The message now says no profiles are saved yet, that Logitech mice normally get them when G HUB links the mouse once, and what to do. English only; other locales keep their existing text for that string.
  • Set up profiles button on the Profiles tab. It shows only when a Logitech mouse with a captured factory image (PRO X 3 SUPERSTRIKE) has finished loading with an empty profile list. After a confirmation it writes the factory profiles with profile 1 active and reloads the list, so G HUB is not needed first. The label is translated in all 10 locales. It reuses .icon-button with theme tokens only.
  • Nothing is written automatically on connect. The setup write is reachable only from that button.

Depends on

mouse-protocol#166 (adds initializeBlankOnboardProfiles and the format 8 factory image). This stays a draft until that is merged and released and the @openmouse/protocol pin 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

  • tsc is clean against the protocol branch, and the app tests pass (266).
  • Looked at the button in a demo preview (since removed): it matches the neighbouring icon buttons.

onyxhq-dev and others added 4 commits October 5, 2026 08:51
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
snekxs marked this pull request as ready for review October 6, 2026 00:16
@snekxs
snekxs merged commit a59a62d into OpenMouse-Project:main Oct 6, 2026
3 checks passed
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants