GMMK long key change times about rgb_keyboard HOT 7 CLOSED

I tried to make it async but probably missed something obvious Image
(I added an event handler to the main file)

Note: I have no idea what im doing ^

from rgb_keyboard.

The official software implements changing multiple keys in a single packet, this software does not (one packet per key is used), that is the main reason for the speed difference. I chose to implement it this way because less reverse engineering effort would be required.

Custom animations are certainly a nice feature, and i would welcome your efforts. A few things i would keep in mind about the potential design:

• The existing code sucks (in some places more than in others), rewriting parts might be good
• Different keyboards use different keycodes to change the individual key colors
• How should animations be defined? I would prefer having animations as executables in a scripting language that simply call rgb_keyboard, mabe a Lua or Python API should be created for that.
• I personally wouldn't bother with the async libusb API as the biggest speedup should come from changing multiple keys in a single packet. However I won't reject it if you got the async API working.
• The key colors are stored on the keyboard, constantly changing them could wear out the flash(?) storage of the controller

As far as capturing USB data goes:
A simple description:
https://github.com/dokutan/rgb_keyboard/tree/master/doc#capturing-usb-data
More detailed explanations:
https://bytepunk.wordpress.com/2017/03/25/reverse-engineering-a-usb-mouse/
https://github.com/pez2001/razer_chroma_drivers/wiki/Reverse-Engineering-USB-Protocol

I hope this answers your questions, feel free to ask if there is anything else.

from rgb_keyboard.

Thanks for the information.
I didnt think about the flash memory, but probably shouldve - there's no way to just change the color without updating the memory I'd assume.

How should animations be defined?
welllll i was just gonna hardcode anything i wanted :P

I tried for async but it didnt work properly for me, everything probably has to go in order anyway.

from rgb_keyboard.

Also before i mess with this more, im probably going to port it to kotlin so i can work with it easily, but i'll at least post how to change multiple at a time once i figure it out

from rgb_keyboard.

It appears to be section based, and sequential. This made all the function keys white


Just one question: Do you have any idea what the first half of the packet is?

from rgb_keyboard.

The first half is just protocol overhead, you generally only have to consider the highlighted data section, with exception of transfer parameters, e.g. endpoints.

from rgb_keyboard.

I'm closing this as your questions seem to be answered and no implementation of a custom animation API is currently planned (due to the flash memory problem).

from rgb_keyboard.