Closed half-duplex closed 5 years ago
Neat!
I'm not sure how quickly I could add this to the KLL compiler, but @jbondeson may be able to do something more easily with the configurator.
@haata I'm using this on my K-Type by copying the Kira config and adding it to my scancode_map.kll with no other modifications to the repo when building the firmware:
### Gamma Correction ###
LEDGamma = 2.2; # Windows defaults to 2.2
gamma_enabled = "1"; # 0 - Disabled, 1 - Enabled
Build environment is Docker Ubuntu
After flashing I'm seeing backlight flicker. Did you come across this in your testing? Is it a current issue, something with Gamma, or something else?
I tried Gamma Enabled with LEDGamma values of 1.0, 1.5, 2.2, and 3.0 and saw flicker on all but the 1.0. Gamma Disabled with all the same values (predictably) had no flickering.
Happy to provide files, details, etc.
@bradyjoh interesting, I'll take a look. I haven't done much testing off gamma correction on Kinetis yet (mostly on SAM4S/Kira).
Flickering confirmed, gonna try a few things.
Edit: I've narrowed it down to the fade control code. When fading is enabled, gamma works no problem, when it's disabled, flickering. Shouldn't take me too long to fix.
@bradyjoh should be fixed now.
Just flashed, I too can confirm it's not flickering when Gamma is enabled and set to 1.0 or 2.2.
HOWEVER, I might be going crazy but I think that Gamma disabled now causes flickering
### Gamma Correction ###
LEDGamma = 2.2; # Windows defaults to 2.2
gamma_enabled = "0"; # 0 - Disabled, 1 - Enabled
Ooops, one sec.
Now try.
Yep it looks good in both modes now. Thanks @haata !
To others that make it here, I just figured out that instead of re-flashing to enable/disable to test Gamma, there's a handy shortcut to use. In a KLL configuration, you can make a map like U"L" : gamma(2);
where the 2 input triggers Gamma on and off when you tap the L key. That change (and the other inputs to the function) can be seen at the line linked here
Colors on my new K-Type were looking awfully washed out and in some cases just plain wrong. It seems that no gamma expansion is applied to user-provided values. They look much better after manually expanding them, but this should be done by the software.
Basically: When taking the input value from the configurator it should put the value in the range 0-1, raise it to the power of $gamma, then put it back to 0-255 (or whatever range is used internally)
What I've been doing manually:
RGB 255,143,0
(orange). Using this value results in a yellow keyboard.gamma = 2.2
which looks good. I haven't bothered to try others.linear_value = round(((color_value/255)**gamma)*255)
RGB 255,71,0
(basically red on monitor because of double gamma expansion)If a manually tuned older config looks "wrong" with this implemented, it can be gamma compressed with this
compressed_value = round(((tuned_value/255)**(1/gamma))*255)
so it'll look correct once color handling is fixed in the tools.