2. Q (to op) : Are there gonna be more mouse key support ( like MOUSE3/4/5 etc. ) or is it something that's only available for specific mouse drivers ? I am just not quite sure how OSes handle I/O, is that even dependant on OS ? If it is, does it matter what drivers are there? Or are those extra mouse buttons just hack arounds of something that already exists ?
I implemented a standard Boot-compatible HID mouse. That means it is limited to 3 mouse buttons. MOUSE4/5 really aren't hard to add, I just wanted it to be as compatible as possible. To be honest, I'm not sure what good it would do. On every mouse I have, MOUSE4/5 are bound to forward/back, which can already be bound to keys on the keyboard.
1. Q : How do you implement Toggle-able modifier keys and what problems would arise from such a feature? What's the main thing to worry about? Just the memory the code uses?
I implement them when a scancode is activated or deactivated. Once the system realizes that something is happening to a modifier key, it looks up how the user has configured that modifier. It then decides how to react. Most of the magic happens on the upstroke. If the key was set as a toggle, the system doesn't send the modifier deactivation to the PC. The only thing it requires is a small bit of memory.
When I was designing my firmware, I intentionally kept away from the major open source firmware (TMK) because I wanted to have a design of my own ("clean room" design). After completing the Epsilon project, I went ahead and looked at Hasu's code. It was very interesting after going through it myself. Unsurprisingly, his code looks and functions completely different from mine. One of the main differences is that he assigns special functions to locations in the layout (keys). I assign special functions to scancodes.
For example. In TMK, you might assign Row 5, Col 0 to TOGGLE(LSHIFT), but on Easy AVR, you would assign R5C0 to LSHIFT and separately configure LSHIFT as toggleable.
This is a fundamental difference between our approaches. His is obviously very configurable for strange and exotic layouts, but mine allows for simpler code that is easy to fit into very small devices. I don't think either way is obviously superior to the other, they're just different ways of approaching the problem.
The feature you've been looking for, Ound, is not exactly mappable in my current software because of this design choice. To be quite honest, I don't know why someone would want to switch back and forth between normal and toggle modes during their daily use in a way that they wouldn't be able to use "Lockable" mode (double-tap to toggle).
The way I see it, these are the possible ways to do what you want with EasyAVR:
1. I redesign the system to work like TMK (unlikely at the moment)
2. You decide on one or the other and keep it
3. You just use Lockable mode. (honestly, I think this is what you want)
4. I add a key that specifically mimics the PokerII behavior. I've done this with other keys (GraveEsc and LockingCAPS)
5. You map LSHIFT to normal and RSHIFT to toggle, and use LSHIFT on both shift keys on one layer and use RSHIFT on both shift keys on the other layer.