-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: LED indicators #999
Conversation
4b320f5
to
67cc21d
Compare
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 |
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? |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few initial thoughts. If you don't want to do this as two PRs, please at least split the code additions into two parts:
- The generic state management and ties into USB and GATT HID systems.
- The LED display handling of the new state.
That will make this way easier to review.
Thanks!
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: ReFil@4733078 which i've been testing across multiple bluetooth profiles as well as usb |
Thanks! I will look into that |
1e33ee7
to
bd722f5
Compare
@ReFil I made a lot of improvements, can you test the latest version? |
bd722f5
to
025bfd9
Compare
Spotted another bug, currently consumer reports dont write. the fix entailed changing Line 261 in 025bfd9
|
Thank you! Fixed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions.
ffb70a5
to
ef49dff
Compare
1065491
to
d27698f
Compare
433a402
to
1a03479
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bortoz Thank you for your patience on this! One or two minor comments on the coding conventions, but otherwise this looks great. I'll get the HID tweaks in a PR right away to get that in, while you work on the couple other comments here.
|
||
#pragma once | ||
|
||
typedef uint8_t zmk_hid_indicators; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually follow the convention of using a _t
suffix for types like these:
typedef uint8_t zmk_hid_indicators; | |
typedef uint8_t zmk_hid_indicators_t; |
} | ||
|
||
zmk_hid_indicators zmk_hid_indicators_get_profile(struct zmk_endpoint_instance endpoint) { | ||
int profile = zmk_endpoint_instance_to_index(endpoint); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int profile = zmk_endpoint_instance_to_index(endpoint); | |
const int profile = zmk_endpoint_instance_to_index(endpoint); |
} | ||
|
||
static void raise_led_changed_event(struct k_work *_work) { | ||
zmk_hid_indicators indicators = zmk_hid_indicators_get_current_profile(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
zmk_hid_indicators indicators = zmk_hid_indicators_get_current_profile(); | |
const zmk_hid_indicators indicators = zmk_hid_indicators_get_current_profile(); |
uint8_t indicators = report->leds; | ||
zmk_hid_indicators_set_profile(indicators, endpoint); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uint8_t indicators = report->leds; | |
zmk_hid_indicators_set_profile(indicators, endpoint); | |
zmk_hid_indicators_t indicators = (zmk_hid_indicators_t)report->leds; | |
zmk_hid_indicators_set_profile(indicators, endpoint); |
#define HID_REPORT_ID_KEYBOARD 0x01 | ||
#define HID_REPORT_ID_LEDS 0x01 | ||
#define HID_REPORT_ID_CONSUMER 0x02 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed you had added these here. I had rolled a similar tweak into #1991 with different naming conventions. Let me pull that out into a small refactor PR (where it should be anyways, and we can then build on it for this and that PR as well.
int err = bt_gatt_write_without_response(peripherals[i].conn, | ||
peripherals[i].update_hid_indicators, &indicators, | ||
sizeof(indicators), true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See chrisandreae@bc824de from the MoErgo folks for a small safety check that would be good here, if this gets called mid-attribute discovery.
@@ -37,6 +37,8 @@ target_sources(app PRIVATE src/behaviors/behavior_reset.c) | |||
target_sources_ifdef(CONFIG_ZMK_EXT_POWER app PRIVATE src/behaviors/behavior_ext_power.c) | |||
if ((NOT CONFIG_ZMK_SPLIT) OR CONFIG_ZMK_SPLIT_ROLE_CENTRAL) | |||
target_sources(app PRIVATE src/hid.c) | |||
target_sources_ifdef(CONFIG_ZMK_USB app PRIVATE src/usb_hid.c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is no longer needed after #2006 was merged since CONFIG_ZMK_USB
now depends on the if
condition
@bortoz Thank you so much for the work on this! I've merged #2041 just now that includes all your core work with the minor changes/additions as noted there. I am truly sad this has taken so long, and I appreciate your persistence in sticking with this. I'm hoping we can build out various status/display bits on top of this now that the core has been merged. ❤️ |
#115
This PR adds support for LED indicators, such as Caps Lock LED and Num Lock LED.