feat(hid): rebind POP Keys' dedicated emoji keys

[RafRaf]

I recently picked up a POP Keys keyboard and wanted to remap the emoji row the same way I remap everything else on my Logi gear (I've actually swapped in some of the spare keycaps it ships with, so what's printed on my keys right now isn't even the stock heart-eyes/crying/smiley/tears set — more on why that doesn't matter below). Turns out OpenLogi has no way to bind those keys at all — 4 of POP Keys' 5 dedicated emoji keys aren't modeled as a ButtonId anywhere. Only the "open emoji panel" key was already covered (KeyEmoji).

This PR adds the missing four as new ButtonId variants (KeyEmojiHeartEyes, KeyEmojiCrying, KeyEmojiSmiley, KeyEmojiTears) and wires their CIDs (0x104–0x107) into the 0x1b04 diversion table, so they're bindable in config.toml the same way KeySearch/KeyDictation/etc. already are. The naming/binding is by HID++ control ID, not by whatever's printed on the cap — since POP Keys keycaps are swappable, that's the only thing that actually stays stable per key.

I only did the config-side plumbing, not a dashboard entry — figured this counts as a small fix rather than a new feature. The Keys tab doesn't render this category of key at all yet (not even the existing 9), so a proper POP Keys render in the dashboard felt like its own, bigger effort and probably deserves a separate PR.

Tested locally on macOS — fmt/clippy/test --workspace all pass, and I confirmed live on my own POP Keys (spare caps and all) that it actually works:

[devices."direct:046d:b365:serial:xxxxxxxx".bindings]
KeyEmojiHeartEyes = { TypeText = "👍" }
KeyEmojiCrying = { TypeText = "❤️" }
KeyEmojiSmiley = { TypeText = "🔥" }
KeyEmojiTears = { TypeText = "😂" }

Happy to adjust naming or scope if you'd rather it done differently.

[greptile-apps]

Greptile Summary

The PR makes four dedicated POP Keys emoji controls configurable through the existing HID++ keyboard-capture path.

• Adds four append-only ButtonId variants with labels and inert defaults.
• Maps CIDs 0x0104–0x0107 into keyboard capture planning and dispatch.
• Documents a POP Keys binding example.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/openlogi-core/src/binding/button.rs	Adds four append-only POP Keys identifiers, labels, and keyboard-key entries without changing existing serialized names.
crates/openlogi-core/src/binding/defaults.rs	Gives the new keyboard controls inert defaults so unbound keys retain native firmware behavior.
crates/openlogi-device/src/session/keyboard.rs	Maps the four dedicated emoji CIDs into the existing generic keyboard diversion and capture flow.
docs/config.example.toml	Documents configuring a dedicated POP Keys emoji control.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Device TOML binding] --> B[ButtonId emoji variant]
  B --> C[CID mapping 0x0104–0x0107]
  C --> D[HID++ 0x1b04 diversion]
  D --> E[Captured button press]
  E --> F[Configured action dispatch]

Loading

_{Reviews (4): Last reviewed commit: "feat(hid): rebind POP Keys' dedicated em..." | Re-trigger Greptile}

[RafRaf]

Just for context

[davidbudnick]

@RafRaf Cool idea, does it make sense for those emoji to be set by the user instead of hardcoding the main ones?

[RafRaf]

@davidbudnick The KeyEmoji* names come from Logitech's own control catalog - each is a fixed HID++ control ID with an official name (e.g. "Loudly crying face"), not something I made up. :) That name's tied to the physical switch, not the keycap sitting on top of it, so swapping caps doesn't change which control you're binding - you can still assign it whatever you want. Here's a couple of spares in place:

[davidbudnick]

@davidbudnick The KeyEmoji* names come from Logitech's own control catalog - each is a fixed HID++ control ID with an official name (e.g. "Loudly crying face"), not something I made up. :) That name's tied to the physical switch, not the keycap sitting on top of it, so swapping caps doesn't change which control you're binding - you can still assign it whatever you want. Here's a couple of spares in place:

Neat! Just double checking thanks for the extra info!

[RafRaf]

Hey @AprilNEA! Rebased onto master since we had a conflict with the wheel-tilt PR — should be clean now. Could you approve / merge when you get a chance?