zmk
zmk copied to clipboard
zmkfirmware
feature: LED indicators
#115
This PR adds support for LED indicators, such as Caps Lock LED and Num Lock LED.
FYI, this seems to have some overlap with #904. It would be nice to make sure we don't end up with competing PWM LED systems.
FYI, this seems to have some overlap with #904. It would be nice to make sure we don't end up with competing PWM LED systems.
LED indicators do not require PWM LEDs, you can use any LED driver supported by Zephyr. I added the PWM LED driver because the one in Zephyr 2.5 is not working properly but it is only a temporary solution until Zephyr is upgraded.
I think it would be better to do two prs, a pr to read the report and another for the implementations
I think it would be better to do two prs, a pr to read the report and another for the implementations
Is there a particular reason for doing this?
I think it would be better to do two prs, a pr to read the report and another for the implementations
Is there a particular reason for doing this?
For two reasons, first so that this is faster and easier to do the code review and second because of what has been working in backlight, the implementation may change, in my design the caplock led is the last led of the underglow, is it possible configure it with your implementation?
For two reasons, first so that this is faster and easier to do the code review and second because of what has been working in backlight, the implementation may change, in my design the caplock led is the last led of the underglow, is it possible configure it with your implementation?
This PR and backlight PR are independent of each other, you can use only one of them or both together without any problem. As I said earlier this PR does not depend on PWM LEDs, any LED driver can be used.
Regarding your behavior, I don't think it's achievable as the underglow API doesn't allow changing individual LEDs (and modifying those API is beyond the intentions of this PR). However the current implementation of LED indicators allows you to implement a custom behavior, you can find more details in the documentation.
Been testing this over the past little while, usb behaviour is flawless after i added a subscriber to update when it's connected to handle state changes whislt disconnected, although i'm having significant trouble getting it to work over BLE, tried windows mac and linux and i cannot make it work, have you got any suggestions?
Been testing this over the past little while, usb behaviour is flawless after i added a subscriber to update when it's connected to handle state changes whislt disconnected, although i'm having significant trouble getting it to work over BLE, tried windows mac and linux and i cannot make it work, have you got any suggestions?
I'm not sure why it doesn't work, but I haven't had a lot of time in the past months to test it properly
i've found the problem, it's that the source is not being set properly in your indexing function in led_indicators.c. i'd reccomend replacing the source index setup with what i've done here: https://github.com/ReFil/zmk/commit/47330785161df4b16bc60ff86ff8d0c787b39fe4 which i've been testing across multiple bluetooth profiles as well as usb
i've found the problem, it's that the source is not being set properly in your indexing function in led_indicators.c. i'd reccomend replacing the source index setup with what i've done here: ReFil@4733078 which i've been testing across multiple bluetooth profiles as well as usb
Thanks! I will look into that
Spotted another bug, currently consumer reports dont write. the fix entailed changing https://github.com/zmkfirmware/zmk/blob/025bfd92900eab6d186a8dac2cc4cff5fc6e68b7/app/src/hog.c#L261 the size from 10 to 12
Spotted another bug, currently consumer reports dont write. the fix entailed changing
Thank you! Fixed
It looks like currently it is not possible to overlay the caps/scroll/num lock onto underglow LEDs. What would it take to make that possible?
It looks like currently it is not possible to overlay the caps/scroll/num lock onto underglow LEDs. What would it take to make that possible?
As I said before, that is a limitation of the underglow APIs and modifying those API is beyond the intentions of this PR.
It looks like currently it is not possible to overlay the caps/scroll/num lock onto underglow LEDs. What would it take to make that possible?
Yes it is posible, I have that working in a local branch
I did the same thing here https://github.com/ReFil/zmk/blob/adv360-beta/app/src/rgb_underglow.c
i have tested this one and seems to work.
one thing i noticed scroll lock does not work but i suspect this is a more general issue on modern computers. did not test kana and compose.
now with the exception of capslock... all the others are kind of academic... i wonder if will not be more useful to add a layer indicator feature in here... more in line with modern firmware
@alinelena thanks for testing!
i wonder if will not be more useful to add a layer indicator feature in here... more in line with modern firmware
Can you elaborate more?
Practically I would like to have leds that indicate which layer is active this is additional to what you did already.
Imagine 4 layers more or less standard layering these days default raise lower and adjust. A simple approach is 1 indicator layer led per non default layer. This gives you 3. Of course if adj is dependent of raise and lower you get away with only 2.
Also these are similar with what you did for lock keys... With the only difference they are local to the keyboard. We can elaborate in discord if interested.
Layer indication is tricky to do with only single colour LEDs, although you can indicate one additional layer I guess. Polarity works have done full colours per layer using extra props in the layer to signal to the RGB code what it should be doing
Here's the commit, feel free to take inspiration if you do want to do layer indication https://github.com/ReFil/zmk/commit/2f7c0420b386637b630693398d28aa4beed6c898
The only tricky bit is layers like adjust the rest you know the state and you just put the right led on or off.you just need a way to track the state of the layer.
One can argue that caps lock is a layer indicator.
The only tricky bit is layers like adjust the rest you know the state and you just put the right led on or off.you just need a way to track the state of the layer.
One can argue that caps lock is a layer indicator.
To clarify, caps lock is a host status and not a layer as it is handled on the keyboard. It is handled differently between mac and windows, as well. (IIRC windows is system wide where mac is board specific but still tied to the host)
They are interacted with pretty differently is the only reason I bring this up.
I am unable to get it to compile using PWM due to a linking issue (SEEMS to point at cmakelist but I am unsure on how to work that one out)
As for the GPIO LED, it updates on my board if I am plugged in via USB but if I disconnect, it no longer updates and will remain in the state that it was in when the board was unplugged and switched to bluetooth only
I am unable to get it to compile using PWM due to a linking issue (SEEMS to point at cmakelist but I am unsure on how to work that one out)
Did you follow all the steps in the documentation? Can you post the compilation output?
ok one issue I have got today... playing with a simple xiao ble today I noticed that using the user led(red/green/blue) on the board seems to have inversed logic... on when caps is off, off when caps is on
you can see an example in here https://github.com/alinelena/zmk/tree/mlego/app/boards/shields/mlego2x2
@alinelena Can you try this change?
led_capslock: led_capslock {
- gpios = <&gpio0 26 0>;
+ gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
label = "Caps lock LED";
};
Have you tried
GPIO_ACTIVE_LOW?
Yes... I think all is needed for these user led is inverted logic can you point to me where you set the state of the led according to the state of capslock? I can change by hand and test. In long term you want an option to account for this behaviour