[Keyboard] Add RGB Matrix support to id67 and add thewerther keymap

[thewerther]

This PR will replace the RGB Light feature with the RGB Matrix feature and also add my keymap folder with a hint on how to have different colors on the underglow leds and per-key leds which was requested in the idobao discord.

Description

• Updated readme with pictures.
• Added everything to make the RGB matrix feature work.
• Added my own keymap folder with some minor differences to the default keymap.

Since this is my first contribution to QMK I'm not sure if the structure in which I added the keymaps are right.
I'm not sure if changing the default lightning to RGB Matrix is okay. But a lot of people asked on the idobao discord for the reactive effect, which unfortunately only works with RGB Matrix.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[fauxpark]

.

[vinorodrigues]

Question: Would this not be a breaking change? - essentially this PR moves the original "RGB Lighting" code to "RGB Matrix" ... given that Matrix is better, there may however be users whom preference the original RGB effects that are not available in RGB Matrix.

Would it not thus be better to have the original config / (partial) code moved to a "V1" sub-folder (keeping the RGB Lighting variant), and then create a "V2" variant with the RGB Matrix (such as kbdfans/kbd67 does)?

Also - I have concerns with the VIA config, moving from Lighting to Matrix will break the VIA config line 5 in the VIA json file and someone will need to push up that change to VIA - thus also breaking existing RGB Lighting based VIA compiled keebs. Making a v1 / v2 means that VIA can have 2 variants too.

[sigprof]

Would it not thus be better to have the original config / (partial) code moved to a "V1" sub-folder (keeping the RGB Lighting variant), and then create a "V2" variant with the RGB Matrix (such as kbdfans/kbd67 does)?

There is some precedent for that: capsunlocked/cu80/v2_ansi and capsunlocked/cu80/v2_ansi/rgb. Not V1/V2 though — suffixes like v1/v2 (or rev1/rev2) are reserved for actual PCB differences.

Making a v1 / v2 means that VIA can have 2 variants too.

Note that this would require assigning a different USB PID value for the new variant.

[vinorodrigues]

suffixes like v1/v2 .. are reserved for actual PCB differences.

We may be in luck - current PCB are marked "ID67H V3.2", so assuming there was V1 and V2 in the past. Also KB's are sold as V1's and new V2's ... both still for sale. Also.. the stand alone PCB is sold as V2

Having said, that /rgb is a solid idea!

this would require assigning a different USB PID value for the new variant.

Yes! ... and this be the problem (with VIA). Maybe something like prefixing the product ID would help create a dissemination with the VIA commits...

#define PRODUCT_ID      0x1067

... idk - just throwing ideas about.

[thewerther]

We may be in luck - current PCB are marked "ID67H V3.2", so assuming there was V1 and V2 in the past. Also KB's are sold as V1's and new V2's ... both still for sale. Also.. the stand alone PCB is sold as V2

Having said, that /rgb is a solid idea!

Okay, so instead of replacing the RGB Lightning feature, I should create a new folder called 'rgb' and add the RGB Matrix implementation there?

this would require assigning a different USB PID value for the new variant.

Yes! ... and this be the problem (with VIA). Maybe something like prefixing the product ID would help create a dissemination with the VIA commits...

#define PRODUCT_ID      0x1067

And for the new '/rgb' config the PID would just be incremented?

[peepeetee]

The PID should not be changed.
Usually (or what I did at least) in this exact situation, replacing rgb light with rgb matrix in place is fine. RGB matrix has all the functionality RGB light has, and if someone want the rgb light effects they can just implement it

[vinorodrigues]

RGB matrix has all the functionality RGB light has

Well.. the effects are totally different. But I get your point, but: In code / compile yes - in VIA no ... VIA has a "LIGHTING" tab, and if you select it with the Matrix code compiled it crashes.

The debate is that users with a VIA compile will not have their VIA behave correctly. And conversely, if one also posts a change to VIA to take on the new effects, then those with the old VIA compile will also have issues.

[vinorodrigues]

@thewerther - hey, a quick one. In file rgb.c, line 39 you comment "Indices are reversed on the physical board, top left is bottom right." on the LED Index to Flag section, which is correct. Another way to see this is that the WS2812 LED address 0 is the bottom-right [Right Arrow] key, and address 1 is the [Down Arrow] ... and so on; from bottom-left to right and up.

But ... this "reversed" approach is also applicable to the LED Index to Physical Position section too. For example, the [Right Arrow], location {224, 64}, that is address 0, and should appear as the very first item. So you need to reverse the sequences for lines 29 to 33.

I'd recently bought a ID67 Bestype and was working on the code base myself but could not test the under-glow LEDs as these are covered on the Bestype - so I never thought to publish it. But if you want to have a look-see at the code head on over to {since deleted} - the code on there fully works with all the animations correctly rendered and correctly centred (albeit with under-glow untested).

*** As is, the matrix animations will not render correctly, especially the rotation based ones. ***

[thewerther]

I corrected the led mapping config, I think everything should be good now.

[thewerther]

I tested the underglow effects and they seemed to not work correctly with the previous config. With this led config all the effects work correctly as far as I could tell by my testing.

[vinorodrigues]

this merge broke things - ID67 does not compile anymore :( . mea culpa! i was compiling another branch. works fine.

[thewerther]

this merge broke things - ID67 does not compile anymore :(

Did you specify the variant you want to compile? E.g. make id67/rgb:default