incorrect mapping with specific buttons

[sdx6]

Information

• ratbagd version (ratbagd --version): 0.17 (libratbag-git on AUR)
• Piper version: piper-git 0.7.r120.gd533d97-1
• Distribution: EndeavourOS
• Device: G502 X Hero
• Kernel version (ex. uname -srmo): Linux 6.7.3-arch1-2

Describe the bug
when binding specific buttons like the G4, G5, and MMB to a keystroke, it adds a bunch of random unrelated keys

(MMB is set to period)

(xev reports something else..)

(piper still thinks its the correct keysym)

To Reproduce
im not sure? this seems like a specific hardware issue
if possible i would like guidance on how to apply my current configuration with ratbagctl

(700dpi)

Steps to reproduce the behavior:
have a g502 x hero
set mmb, g4 or g5 to a keystroke

Logs

ratbagd.log

Additional context
i tried with other mice and with other machines and its specifically an issue with the g502 x hero it looks like (but i dont know why)

[Bestest-Coder]

Can confirm, this happens for me as well. If I bind G6 or G7 on the G502 Hero to a macro of a single key (say n) it will bind N, as well as ctrl alt shift and meta
Piper version 0.8
ratbagd version 0.18

[a-aerts]

Same issue for me, G502, G7 and G8, if I set G8 to KEY_1, it gets saved as one (can be seen in Piper and through CLI), but evtest shows it's also pressing meta, shift etc.

Interestingly, after restarting ratbag service and checking the bindings again it changes to the glitchy form..

^ it was just KEY_1 until I've restarted ratbagd and piper.

Furthermore, if I set G8 to KEY_1 on Profile 1 (active by default) with ratbagctl yelling-zokor button 7 action set key KEY_1, it is being saved as:
Button: 7 is mapped to key 'KEY_1'
After restarting the ratbagd it changes to:
Button: 7 is mapped to macro '↕KEY_1'

If I do the same on Profile 0, it changes into:
Button: 7 is mapped to macro '↓KEY_LEFTMETA ↕KEY_1 ↑KEY_LEFTMETA' (which is the result I'm seeing in evtest)

After probing in ratbagd a bit, I've discovered that when a key is being set, it is being set as a key, but if I kill the daemon and run the Piper again, a get_macro function is being called instead:
https://github.com/libratbag/libratbag/blob/dcc5def3d6fba1a39723689121b6de076b0747d1/ratbagd/ratbagd-button.c#L203

which at some point overwrites a KEY with a MACRO. ratbagd_button_set_macro didn't get called for that.

So I think it's an issue with the daemon and not Piper itself.

Piper version 0.8
ratbagd version 0.18