Custom colors via file

[luv4bytes]

Hey Sebastian,

so far custom colors can be set via command line arguments. However specifying all keys on the command line creates huge command constructs.

For that reason I'd like to implement some way of specifying the individual key colors in a separate file. Maybe in a JSON file? The path to the file could be passed via argument. Something like ./cherryrgb-rs --key-color-file... .

Any ideas or concerns :)?

[skraus-dev]

Sounds good.

Format

Two options I see here:

• A) A json list of strings that contain colors in rgb8. The implication is, that this file is definitive, aka. sets the colors starting from index 0

Example:

[
  "ffeeff",
  "00ffff",
  // .. snip ..
   "0000ff"
]

• B) An indexed format, f.e.

{
  "0": "ffeeff",
  "1": "00ffff",
  "42": "0000ff"
}

• C) Something different than json?

This enables overrides to existing colors, see point Behaviour

Behaviour

When choosing option B, a command-line switch could be introduced, as in --keep-existing-colors, to only override colors that are defined in the currently passed file. Old colors from a previous run would persist.

[luv4bytes]

I'd pretty much like option B. It would make things a bit more flexible.

One question that came to my mind was if there is a way to get the number of keys from the keyboard via command. That would make it possible to generate a template for the connected keyboard so that you'd automatically have the number of available keys in the file. Although I think the state fetching is still a black box and I'm not even sure if this would be the right spot to search for this.

[skraus-dev]

I'd pretty much like option B. It would make things a bit more flexible.

Agree, I prefer that one as well.

One question that came to my mind was if there is a way to get the number of keys from the keyboard via command.

Yeah, either its delivered as a HID response.. or it's harcoded into the original Cherry Windows App, in relation to the VID/PID/Model.

Although I think the state fetching is still a black box and I'm not even sure if this would be the right spot to search for this.

Correct, just opened issue #17 regarding that.

[luv4bytes]

Yeah, either its delivered as a HID response.. or it's harcoded into the original Cherry Windows App, in relation to the VID/PID/Model.

Another approach for now would be to write the template generators for each keyboard with the hard-coded number of keys. Basically count keys and test if the number of keys actually works. Not as elegant as a universal generator that works with a response from the keyboard though.

[skraus-dev]

Yep, we can do that.

Additionally, we need a way to query the keyboard for already-set colors...

[luv4bytes]

Yeah, I'll probably split this up into two parts. First part will be just reading the color file and setting the colors accordingly. Second part will be the --keep-existing-colors handling. Since we need the right queries for this like you said.

Would it make sense to create a new issue for the template generators?

[skraus-dev]

Yeah, I'll probably split this up into two parts. First part will be just reading the color file and setting the colors accordingly. Second part will be the --keep-existing-colors handling.

Yep, sounds good!

Would it make sense to create a new issue for the template generators?

I just opened #19 for that ;)

[luv4bytes]

First part of this issue, the color profile file is requested in #21.

[felfert]

Yep, we can do that.

Additionally, we need a way to query the keyboard for already-set colors...

I'm afraid this is not possible. I did some more analyzing of the Windows utility:

1. Create snapshot of Windows-VM's disk
2. Attach keyboard to VM
3. Set some custom colors
4. reboot
5. Reattach keyboard to VM - Colors were unchanged in GUI
6. Restored snapshot and reboot VM
7. Reattach keyboard, all previously set colors are gone.

This is proof, that Cherry's windows utility stores the state somewhere on disk.

I Identified 3 files that get written by the utility. These are all in

C:\Users\<USERNAME>\AppData\Local\CherryControlCenter\

• ScenefileList.ini References the json file below as "profile"
• 2023_03_14_08_47_16_848.Json Grows over time, new states get appended. The basename is referenced in ScenefileList.ini as profileUUID
• color_option_info.config Gets overwritten, appears to contain the current state of the color selector dialog.

I could find the RGB values that I had set in step 3 in the json file, but this part looks more like a GUI state, not a keyboard state. Did not examine registry.

Conclusion:
In order to implement a --keep-existing-colors functionality, we should persist the CustomKeyLeds vector to local file and when --keep-existing-colors is specified, restore it before setting individual key colors. Will implement that now ...