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

Adds configuration-side support for rebinding four dedicated POP Keys emoji controls.

• Adds four append-only ButtonId variants with labels and no-op defaults.
• Maps HID++ CIDs 0x0104–0x0107 into the keyboard diversion table.
• Documents a per-device emoji-key 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 emoji button identifiers, labels, and keyboard-key registrations.
crates/openlogi-core/src/binding/defaults.rs	Assigns the new keyboard controls no-op defaults so unbound keys retain native behavior.
crates/openlogi-hid/src/session/keyboard.rs	Maps the four POP Keys control IDs into the existing HID++ keyboard diversion flow.
docs/config.example.toml	Documents binding a dedicated POP Keys emoji control through per-device configuration.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    Config[Device binding in config.toml] --> Button[KeyEmoji ButtonId]
    Button --> CID[HID++ CID 0x0104–0x0107]
    CID --> Divert[0x1b04 control diversion]
    Divert --> Event[Captured button event]
    Event --> Action[Configured action]

Loading

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into feat/pop-keys..." | 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!