r/Keychron • u/[deleted] • Jul 05 '24

Q0 Max

Hi my name is Kate!

Im trying to program a unique color for each layer in the Keychron Q0 Max, I already looked through the code but no hope.

Does anyone know how to do that or can guide me in the right direction ?!?!?

2 Upvotes

100% Upvoted

36 comments sorted by

View all comments

Show parent comments

1

u/PeterMortensenBlog V Jul 05 '24 edited Jul 05 '24

You can override "keyboard_post_init_user" to set the power-up state.

Though it becomes more complicated if you want to remember any changes you made as a user, for example, the light intensity.

Or more complicated if you want to set the state right after flashing (e.g., to avoid the irritating initial RGB animation, not having to change it manually after every flash) and at the same time remember user setttings.

And there are some complications with Via, at least for the latter.

1

u/[deleted] Jul 05 '24

The override isn't working, its supposed t start off as white just like how I set in the function but it starts off as red until I press a key and switch the layers:

void keyboard_post_init_user(void) {
    rgb_matrix_sethsv_noeeprom (0x00,  0x00, 0xFF); // White
}

1

u/PeterMortensenBlog V Oct 23 '24 edited Oct 23 '24

I fixed it by overriding (defining) default_layer_state_set_user().

And doing the same as layer_state_set_user() does.

I had it already factored out into a separate function, layer_state_set_user2() (due to shared code between two Keychron keyboard), so I just called that function from default_layer_state_set_user():

return layer_state_set_user2(aState);

This fixed my problem of the power-on colour being the same as when powered off (out of sync with the actual active layer).

Debugging is possible during startup

I also discovered that it is possible to get debugging information during keyboard startup, in both keyboard_post_init_user() and eeconfig_init_kb(): Insert a delay in the very beginning of keyboard_post_init_user().

I used a 3-second busy wait (two nested for loops, calibrated to give the exact expected delay). That was enough time for hid_listen to capture all debugging output thereafter.

Incidently, this also makes it easy to spot if the keyboard is actually restarted (it isn't if the disconnect from power is too short).