zmkfirmware
feat(split): Transfer arbitrary tagged data from central to peripheral
Currently the only mechanism for data transfer for secondary features (underglow and backlighting primarily) is through the behaviour invocation process, this can only hander user initiated changes, so automatic state changes are missed and the halves state can go out of sync if the central is changed with the peripheral disconnected. Some new features currently in PR initalise a new characteristic for central-> peripheral data transfer however for infrequently updated things abstracting it away means there's not a variety of implementations in the split source files. This introduces a new mechanism by which a data tag, size value and up to 16 bytes of data can be transferred from central to peripheral(s). I tried 32 bytes but ran into some MTU limitation. The data tags are handled in an enum and, in a similar manner to the zephyr sensor channels, additional tags can be defined separately from the current ones and passed to this system without issue. There are currently 5 tags defined, one each for underglow and backlighting, one for the upcoming HID indicators work and one for keymap state (which could be used for passing layer information to a peripheral display widget). the fifth is a marker to show the start of the unallocated ranges for custom usages. That way any future custom uses automatically get "bumped down" as new upstream uses get added seamlessly without any conflicts. This also implements this feature for both RGB underglow and single colour backlighting for a more seamless lighting experience.
This should resolve https://github.com/zmkfirmware/zmk/issues/1494 for RGB and backlighting
This has been rebased to solve the merge conflict as well as adding the ability to send keymap layer state to the peripherals for peripheral display widgets/rgb indications
This could be expanded to include a peripheral side listener for the remaining global locality behaviours (reset, bootloader and ext power) with the intention of superceding the locality system, keen to hear other people's opinions on this idea
Rebased after Zephyr 3.5 update, need to do some testing to confirm nothing broke
Tested all 4 data channels and confirmed, RGB state, backlight state, HID indicators and keymap state all get successfully transmitted to the peripheral , a display widget or custom RGB underglow implementation can subscribe to the zmk_split_data_xfer_event event and process information from the central. automatic state changes are transferred as well. By disabling *_AUTO_OFF_IDLE on the peripheral for RGB and backlighting the lights stay in sync throughout all state changes on the central be it automated or manual.
The zmk_split_peripheral_status_event event is now triggered correctly however it usually triggers before the connection has had time to process. As a result the central often fails to update the peripheral on reconnection after a power cycle. Not sure how to solve this in a good way, would appreciate any suggestions on this
It has been over 3 months and it seems no review has taken place (don't see any review comments). Is something still pending?
It has been over 3 months and it seems no review has taken place (don't see any review comments). Is something still pending?
From my perspective it's ready for a preliminary review
@skewty I am not one of the maintainers, but have been involved in the project for a while and have submitted a few PRs, so here are my 2 cents...
(Which are my opinions alone and do not represent the views of the project or maintainers. I could also be completely wrong about everything here adn they might disagree with it all.)
The zmk maintainer team is very small, the userbase is quite big and the amount of PRs submitted is a lot. There is no way they could review everything and schedule each PR based on the time the PR has been open.
I imagine they have an internal roadmap of the improvements they want to get in and not all the PRs match that roadmap.
On top of that, each feature has a cost, because most of the time the original person submitting it, won't be maintaining it. Updating zephyr, the underlying RTOS, frequently requires a lot of modifications to the code base. Once a feature is merged, all of that work is dumped on the maintainers.
Additionally, a lot of features are submitted by developers who are not familiar with zephyr and zmk. So many features work, but are not implemented in the correct and maintainable way. I'm not saying it's the case with this PR, but it's just one of the things that must be considered.
So, considering all of this, I would recommend you learn how to maintain your own fork with all of the PRs you want to use. It's really not very difficult. Urob's guide is a great intro: https://gist.github.com/urob/68a1e206b2356a01b876ed02d3f542c7
That's the beauty of open source. You can be independent and include all teh features you want without relying on the maintainers prioritizing the features you want.
