How to make my own keyboard support the light adjustment function on VIA

[Pattttta]

Hi guys, this is my first post here on geekhack, I'm actually new to the hobby so there's a lot of stuff I don't know about (especially firmware, software stuff).

I wanted to make this keyboard mainly because I saw a video about KBDFANS MAJA posted by someone on youtube, and I liked its layout because it's ergonomic and has independent arrow keys. But they don't seem to sell this model right now and the price is a bit too expensive for me, so I was thinking to build a gasket mounted stack acrylic case version by myself.

At present, I have completed the production of the acrylic case, the positioning plate and the sandwich cotton. For PCB I asked a friend to draw the PCB for me to make it supports per key RGB, underglow. By the way it uses a Atmega32u4 chip.

Right now the PCB is still under production and I generated the hex file via keyboard firmware builder. The current problem is how can I use VIA, and be able to use the RGB configuration function on VIA for my per key RGB and underglow such as brightness adjustment, color adjustment. I want it to have multiple lighting effects adjustable on VIA  for both per key RGB and underglow, what do I need to do and how do I start. Because I saw a video on youtube, the keyboard used in the video is NK65, I want to know how can I make my keyboard achieve the same function.

By the way, thanks in advance for this platform and the people who are willing to help me!

[nevin]

kbfirmware is a good starting point, but you're going to want to compile from source to implement the LED stuff.
kbfirmware uses and old snapshot of QMK and is not current or as configurable as compiling from source.
https://github.com/qmk/qmk_firmware
https://docs.qmk.fm/#/

the keyboard used in the video was an NK65 entry edition with the fixed layout PCB NK65 V1.4. so use this as the basis/example for implementing the RGB in your firmware. yes, the layout is different, but you're just looking at the RGB implementation from this firmware.
https://github.com/qmk/qmk_firmware/tree/master/keyboards/novelkeys/nk65
- also note, they are using an STM processor instead of a 32u4
- truthfully, it's the most complete example of rgb implementation in VIA that i've seen. (lighting support in VIA is rather new) ... and there may be other good examples, but admittedly i'm not an RGB guy, so i don't keep up on current RGB boards.

- post or send me your KLE layout link as well as the JSON from kbfirmware (or zipped firmware folder from kbfirmware) and we can start to knock this together.
- i've added VIA support to a handful of handwired one-off boards that are not in any repo.
- mechmerlin does some wonderful streams explaining building QMK firmware and adding VIA support (look for his porting & via videos)
      https://www.youtube.com/c/MechMerlin/featured

[suicidal_orange]

Does the 32u4 have enough memory for per key RGB stuff?  Maybe things have changed but I was under the impression it doesn't.

[nevin]

i'm not sure, you might be right though.
i've done handwire stuff but never pcb design.

... at this point, i was just trying to push them in the direction they need to go to. compiling from source, a good fw example, etc...

or jump on the wait list for the maja pcb (if the whole kit is too expensive)
https://kbdfans.com/products/maja-mechanical-keyboard-pcb
.... actually, looking at source, the maja looks like it's 32u4 (might be limited to the number of RGB animations?)

[Pattttta]

kbfirmware is a good starting point, but you're going to want to compile from source to implement the LED stuff.
kbfirmware uses and old snapshot of QMK and is not current or as configurable as compiling from source.
https://github.com/qmk/qmk_firmware
https://docs.qmk.fm/#/

the keyboard used in the video was an NK65 entry edition with the fixed layout PCB NK65 V1.4. so use this as the basis/example for implementing the RGB in your firmware. yes, the layout is different, but you're just looking at the RGB implementation from this firmware.
https://github.com/qmk/qmk_firmware/tree/master/keyboards/novelkeys/nk65
- also note, they are using an STM processor instead of a 32u4
- truthfully, it's the most complete example of rgb implementation in VIA that i've seen. (lighting support in VIA is rather new) ... and there may be other good examples, but admittedly i'm not an RGB guy, so i don't keep up on current RGB boards.

- post or send me your KLE layout link as well as the JSON from kbfirmware (or zipped firmware folder from kbfirmware) and we can start to knock this together.
- i've added VIA support to a handful of handwired one-off boards that are not in any repo.
- mechmerlin does some wonderful streams explaining building QMK firmware and adding VIA support (look for his porting & via videos)
      https://www.youtube.com/c/MechMerlin/featured

Oh, It seems difficult.
- Regarding the processor, I use 32U4 mainly because I see many QMK/VIA compatible keyboards are using it and on kbfirmware there is also 3 options to choose so I didn't know what other processors I could choose because I'm really a newbie.  I actually know that I should choose a processor according to my needs, but I don't have any concept of what kind of processor should I choose for my needs.

- So if I choose to use a processor of STM, what should i do to make this firmware.
- I will post the KLE raw data and the zipped firmware folder here.

Thank you for all the material and information provided.

[Pattttta]

Does the 32u4 have enough memory for per key RGB stuff?  Maybe things have changed but I was under the impression it doesn't.

Yeah. I actually don't know which processor should I choose  I choose 32u4 mainly because I saw many QMK/VIA compatible keyboard are using it.

[nevin]

@Pattttta great, thanks. we should be able to get you a working setup from source.

how's the pcb coming along? has your friend done keyboards before?
- look at LED Matrix Lighting for the per key rgb (look into driver for per key leds for your pcb)
https://docs.qmk.fm/#/feature_led_matrix?id=led-matrix-lighting
- and use RGB Lighting for the underglow
https://docs.qmk.fm/#/feature_rgblight
(pay attention to supported components)

we might have to get creative with the switch matrix to save some i/o pins for the lighting
- it's a larger board (more rows/columns than a 60% or smaller)
- was thinking something like gipetto’s crushed paper matrix
   https://geekhack.org/index.php?topic=103573.msg2840939#msg2840939
...nevermind... was thinking of another board someone is asking questions about.

@suicidal_orange  it might be memory, but it's probably more i/o as well for the transition to the newer STM processors. haven't really done any research into them yet as support is really sporadic as well.

[Pattttta]

@Pattttta great, thanks. we should be able to get you a working setup from source.

how's the pcb coming along? has your friend done keyboards before?
- look at LED Matrix Lighting for the per key rgb (look into driver for per key leds for your pcb)
https://docs.qmk.fm/#/feature_led_matrix?id=led-matrix-lighting
- and use RGB Lighting for the underglow
https://docs.qmk.fm/#/feature_rgblight
(pay attention to supported components)

we might have to get creative with the switch matrix to save some i/o pins for the lighting
- it's a larger board (more rows/columns than a 60% or smaller)
- was thinking something like gipetto’s crushed paper matrix
   https://geekhack.org/index.php?topic=103573.msg2840939#msg2840939
...nevermind... was thinking of another board someone is asking questions about.

@suicidal_orange  it might be memory, but it's probably more i/o as well for the transition to the newer STM processors. haven't really done any research into them yet as support is really sporadic as well.

My friend hasn't finished the PCB part, because this is his first time designing a keyboard PCB so I gave him a PCB of the keyboard I used before which also uses a 32U4 processor with per key RGB and underglow  so he has to clone the PCB first and draw the schematic. After that he will design the PCB of my keyboard based on the schematic. Because he has his own job so...

- However he's almost done with the PCB clone and he told me he would finish the design in a few days after cloning the PCB.
- My another question is should I change the processor to STM instead of 32U4, because if so because in that case I need to tell him to change the the processor.
- I actually checked the QMK documentation myself, but since I'm not a programmer, I found it too difficult for me.

[Pattttta]

So if I can find a programmer, will it be much easier like I just need to send him the firmware file of NK65 and he will know how to apply that source of RGB on my layout.

[suicidal_orange]

What is the schematic you sent your friend?  Before you send tit to be made we can build the firmware and see if it's too big.  No point making more work for your friend if it no change is needed.

it might be memory, but it's probably more i/o as well for the transition to the newer STM processors. haven't really done any research into them yet as support is really sporadic as well.

Yes the 32u4 does run out of pins too, that's the main reason it gets swapped out.  Few new DIYers go for per key RGB so the memory limitation is less commonly hit but there is (or at least was) some scenario where it was.  It's increasingly sounding like this isn't it but maybe it's only a problem with WS83??s and using a driver gets round it (or the other way round)

The bigger (RAM, ROM and I/O) chip that is well supported is the AT90USB1286 as found on the Teensy 2.0++ so if a swap is to be made that would be my choice.  Unless the schematic this is being based on uses the same LED driver as the NK65 meaning it would only be a matter of changing the pins in the firmware and the RGB stuff would just work.

[Pattttta]

What is the schematic you sent your friend?  Before you send tit to be made we can build the firmware and see if it's too big.  No point making more work for your friend if it no change is needed.

it might be memory, but it's probably more i/o as well for the transition to the newer STM processors. haven't really done any research into them yet as support is really sporadic as well.

Yes the 32u4 does run out of pins too, that's the main reason it gets swapped out.  Few new DIYers go for per key RGB so the memory limitation is less commonly hit but there is (or at least was) some scenario where it was.  It's increasingly sounding like this isn't it but maybe it's only a problem with WS83??s and using a driver gets round it (or the other way round)

The bigger (RAM, ROM and I/O) chip that is well supported is the AT90USB1286 as found on the Teensy 2.0++ so if a swap is to be made that would be my choice.  Unless the schematic this is being based on uses the same LED driver as the NK65 meaning it would only be a matter of changing the pins in the firmware and the RGB stuff would just work.

Is that means I just need to change the layout(the rows and column stuff) in keymap.c and the pins in config.h and then compile into a hex file then I can just use it?

[suicidal_orange]

If your board is using the same controller chip, RGB control and the same number of keys/LEDs as an existing one yes - a couple of easy changes to the pins and it will just work.

[Pattttta]

If your board is using the same controller chip, RGB control and the same number of keys/LEDs as an existing one yes - a couple of easy changes to the pins and it will just work.

Thank you! I will give it a try.


Btw, I have checked the every files about NK65 on github still couldn't find out what RGB control it uses. In the rules.mk file, I can only see that the MCU is STM32F303, and the board is QMK_PROTON_C.
- From the video about NK65, I saw that there are 2 chips on the back of the PCB, but I don't know what the other chip is, whether it is responsible for RGB control
- Do you know what is the RGB control of NK65?

[nevin]

yes, what board did you give your friend to "clone"?

led driver on nk65... no, don't know what it is, i don't have one and i doubt it's listed anywhere.

yes, big fan of AT90USB1286 (teensy ++2.0) for large boards.

let me do some figuring / compiling and see what we can come up with. .... if the 32u4 is feasible.

[suicidal_orange]

nk65.c is where that's defined, it uses IS31FL3733

[nevin]

oh, nice.
so, slightly different than the IS31FL3731 that's noted in the documentation...
nevermind... IS31FL3733 is also listed.

[Pattttta]

oh, nice.
so, slightly different than the IS31FL3731 that's noted in the documentation...
nevermind... IS31FL3733 is also listed.

the board I gave to my friend is a MW65 RGB version

https://github.com/qmk/qmk_firmware/tree/master/keyboards/mwstudio/mw65_rgb

[nevin]

the board I gave to my friend is a MW65 RGB version

.... even better starting point... (it's already 32u4)

is there anything the MW65 doesn't do that you saw in the NK65 video that you want the new board to do? (or just couldn't find a MW65 video?)

- MW65 is using a simple 5x15 matrix which will also work for your new board.

don't know if you know this... i was poking around in the MW65 git folder and it looks like VIA support was added less than a month ago. (21 days as of this morning)

[nevin]

also, got your layout into VIA (though not in their repository)

[Pattttta]

the board I gave to my friend is a MW65 RGB version

.... even better starting point... (it's already 32u4)

is there anything the MW65 doesn't do that you saw in the NK65 video that you want the new board to do? (or just couldn't find a MW65 video?)

- MW65 is using a simple 5x15 matrix which will also work for your new board.

don't know if you know this... i was poking around in the MW65 git folder and it looks like VIA support was added less than a month ago. (21 days as of this morning)

- Yes, more than a month ago, if you want to use VIA on MW65, you need to import the json file in VIA every time. At present, it is mainly the RGB configuration function on VIA that MW65 doesn't have and I want it to have on my new board.

- As you just mentioned this problem, I also want to know, how can I make VIA automatically detect my board without importing the json file every time.

[Pattttta]

also, got your layout into VIA (though not in their repository)
(Attachment Link)

Wow, how did you do that 

[nevin]

- As you just mentioned this problem, I also want to know, how can I make VIA automatically detect my board without importing the json file every time.

the firmware and json file would have to be submitted to their respective repositories.

the via layout...  how.... VIA's documentation & watching mechmerlin (also a QMK contributor) explains it well in his series porting with port.
https://www.youtube.com/c/MechMerlin/videos
https://www.twitch.tv/mechmerlin

i'm not familiar with either board or their capabilities or really anything more than basic underglow when it comes to rgb stuff.
- i can, look at the code and see the differences between the two though.
- should probably involve someone with more rgb experience to get where you want to go.

the MW65 uses the built in basic rgb matrix driver (WS2812)

Code: [Select]

RGB_MATRIX_ENABLE = yes
RGB_MATRIX_DRIVER = WS2812
the NK65 uses (is31fl3733)

Code: [Select]

#include "drivers/led/issi/is31fl3733.h"as well as the processor being (STM32F303)

MCU = STM32F303

- again, i don't know if this is required for the more advanced rgb control or not.

[Pattttta]

- As you just mentioned this problem, I also want to know, how can I make VIA automatically detect my board without importing the json file every time.

the firmware and json file would have to be submitted to their respective repositories.

the via layout...  how.... VIA's documentation & watching mechmerlin (also a QMK contributor) explains it well in his series porting with port.
https://www.youtube.com/c/MechMerlin/videos
https://www.twitch.tv/mechmerlin

i'm not familiar with either board or their capabilities or really anything more than basic underglow when it comes to rgb stuff.
- i can, look at the code and see the differences between the two though.
- should probably involve someone with more rgb experience to get where you want to go.

the MW65 uses the built in basic rgb matrix driver (WS2812)

Code: [Select]

RGB_MATRIX_ENABLE = yes
RGB_MATRIX_DRIVER = WS2812
the NK65 uses (is31fl3733)

Code: [Select]

#include "drivers/led/issi/is31fl3733.h"as well as the processor being (STM32F303)

MCU = STM32F303

- again, i don't know if this is required for the more advanced rgb control or not.

The screenshot you posted I don't know which json file do you used to load draft definition. Becasue I tried use the json file from kbfirmware but it shows 'SyntaxError: Unexpected token...'
I have read the documentation from VIA and also watch the video from mechmerlin about VIA and QMK but still cannot find out the reason.

Thanks again for all answering all my questions.

[suicidal_orange]

This looks to be the magic bit, it's at the top of nk65.h but not in mw65_rgb.h:

Code: [Select]

#include "../wilba_tech/wt_rgb_backlight_keycodes.h"
#include "via.h"

[nevin]

@Pattttta - it's a json file i cooked up. will send it to you then
- this json file is only half of the equation though, the other half is in the firmware to enable via compatibility.

@suicidal_orange -  yes, they definitely handle the rgb differently
- my question is... if you go the NK65 route, does it need to be an STM processor? (little out of my depth here)

[Pattttta]

Ok, thank you very much, I have watched a lot of Mechmerlin videos about QMK/VIA, if I still have questions and I can't find the answer, I will continue to ask you, thank you very much for your help.

[nevin]

here's the layout json for via
 Pattttta Alice.json

and depending on led implementation in the firmware, lighting info might not need added to this json file.
- the NK65 json is just the layout. rest of the info for VIA is pulled from firmware.

[Pattttta]

here's the layout json for via
(Attachment Link)

and depending on led implementation in the firmware, lighting info might not need added to this json file.
- the NK65 json is just the layout. rest of the info for VIA is pulled from firmware.

Hi Nevin. I have finished the design and production of the PCB. Everything works fine except the undergolw. For underglow and RGB I used 2 different pins of 32U4 to control but after I flash the hex file from kbfirmware which I fill in the correct pins information for WS2812 and backlight (I assume it refers underglow), The underglows just does't light up at all and everything else works fine.

Could you help me with this from coding for enable underglow ? May I have your other contact so I can send you the schematic.

[nevin]

pm sent