Support for the QMK firmware of AnnePro 2.

[blaa]

Based on the previous work on the original Obins AP2 firmware. I mostly
replaced the protocol parts and wrote parts for main chip in open
firmware. I made it mostly to get KeyboardVisualizer to work. ;)

Requires a patched AP2 QMK firmware (not yet upstream):
https://github.com/blaa/qmk_firmware/tree/keyboard-annepro2-openrgb

Could be done better in multiple ways:

• AP2/QMK could support QMK openrgb controller. It's much more
  complicated and requires a keyb definition in the firmware. Also AP has
  a separate LED chip which doesn't work well with the way QMK does
  things.
• Some code could be shared with Annepro2 controller (led definitions
  for example).

[blaa]

Demo: https://pliki.xyz/index.php/s/DKfpbnPWd44Yeqg
In general that's Request For Comments if it can work like that or you'd like to merge some code with Obins AnnePro2 controller.

Currently the code for open Annepro is in a merge request too, so I guess this should wait at least for that code to merge.
Related: OpenAnnePro/qmk_firmware#48

[blaa]

I tested it and it worked on Linux, but Annepro folks tested it with Windows and the keyboard doesn't receive the first RAW HID byte (rest seem more/less ok starting from the second), so something is probably broken. Any ideas what it might be?

[CalcProgrammer1]

Are you aware of the QMK OpenRGB protocol?

https://github.com/Kasper24/QMK_OpenRGB

If you can get this protocol working on the keyboard I would prefer that over creating another QMK protocol. QMK has their own official protocol "XAP" in development which I do plan on supporting when it's ready, plus the VIA/VIAL project has "vialrgb" which is an RGB control extension to VIA I may eventually support as well. I don't think it makes sense to develop yet another protocol for one specific QMK keyboard.

[blaa]

I'm aware of it - that's the first dot-point in my question and actually first thing I tried to get running. It was pretty complicated for what I was trying to get (the direct mode). AFAIK required keyboard layout on the side of keyboard - unsure how it will impact RAM usage. Current solution was simple on QMK side, closer to ~20 lines of code.

I can try to use it again though, since know I understand everything better - Still, have you got any idea why current implementation works for Linux and drops first byte in HID messages (on windows)? That's something I don't understand and might bite me later.

[blaa]

We've developed a version that uses the QMK interface, so this is now obsolete.