[Feature Request] Combos per split keyboard half

[LukaOber]

Thanks for creating and maintaining this library, it has been a joy to work with so far.

I am trying to create a firmware for a keyboard that is close to artsey which makes heavy use of combos. I have two mirrored halves where each half is able to produce any key of the whole keyboard. When I use the two halves together in a split configuration I accidentally hit a lot of combos I do not want.

Let's say I have a combo where when pressing 'A' + 'B' the keyboard sends a 'C', this is working great when just using one keyboard or just one half. But when I try to type quickly on both sides in an alternating pattern I press 'A' on the left keyboard and quickly after 'B' on the right keyboard it produces a 'C' because the combos are not specific to each half.

I would like to see a feature where the combos can be made keyboard specific, would that be something which might be possible in the future? I am not familiar with the rmk code so I have no idea if this would be easy to implement or an architectural nightmare with the current process of how split keyboards work. Using the keyboard not as a split configuration but instead as two singular ones is sadly not an option as it would greatly hinder the way to efficiently type capital letters and other combos for me.

[HaoboGu]

I think it's possible, but requires some architecture refactoring. Now the keyboard doesn't check where the keyboard event comes from.

[scottlamb]

I'm confused why combos operate at the level of abstraction they do: keycodes instead of key positions. Am I correct in thinking that if you could define combos in terms of key positions, that'd satisfy this use case?

As a different example of the kind of problem this causes, I'm trying to use the same key position (labeled slash on a US qwerty keyboard, left of the right shift) for a .+/ = \ combo and to produce right-ctrl if held. It's not working as I'm hoping...but I'm also not really sure if this is meant to be a supported use case and the details of what's intended. Like, is the tap-hold applied first, and if it produces a slash, then that's put into the combo? I don't know! I feel like there would be a different, potentially better, answer to how this works if it operated at the key position level.

[HaoboGu]

I'm confused why combos operate at the level of abstraction they do: keycodes instead of key positions. Am I correct in thinking that if you could define combos in terms of key positions, that'd satisfy this use case?

RMK currently uses keycode-based combos because that is the only type Vial supports. And yeah, defining combos based on key positions is exactly what I want for RMK as well.