zmk
zmk copied to clipboard
zmkfirmware
feature(split): add split-side encoder support
This PR adds support for encoders on the peripheral side. It adds a new characteristic on the GATT service that the central subscribes to.
I only tested this on my own split Kyria.
@petejohanson friendly ping - could you take a look at this when you have some time? i've been happily using it on my kyria split for a couple weeks.
I can't comment on the code, but I used this branch successfully on my v1 Sofle; haven't had any issues. I do not have oled or underglow so I can't regression test those.
I was able to use these changes and have tested that the encoder works on the secondary side of my wireless Kyria (with OLEDs). Everything appears to work as expected. The build container does report some warnings due to this code but the build doesn't fail so maybe that's ok?
I also just noticed that this also worked for having different encoder keys defined per layer. Very nice!
Didn't work on my BT nice!nano wireless Kyria. I'd test wired but i think it shorts the battery if I attach a TRRS cable.
I have tested this for a month+ on Rollow and it works great. I did need to have both halves encoders on different pin out's, other than that everything works as assumed.
Works great on nice!nano Kyria. Only comment is that my encoders have a different resolution than default. So I put on my .keymap
&left_encoder { resolution = <2>; };
&right_encoder { resolution = <2>; };
Somehow the &right_encoder parameter was ignored. I had to change the .dtsi file to have desired encoder resolution.
Are you running this on a wireless nice!nano Kyria setup @yannickjmt ?
I wasn't able to get it working on my wireless nice!nano Kyria and I'm wondering if I did something wrong while building it.
Thanks for the encoder resolution tip btw, I was wondering why my left encoder took 2 clicks per key press.
Works great on nice!nano Kyria. Only comment is that my encoders have a different resolution than default. So I put on my .keymap
&left_encoder { resolution = <2>; }; &right_encoder { resolution = <2>; };Somehow the &right_encoder parameter was ignored. I had to change the .dtsi file to have desired encoder resolution.
Are you running this on a wireless nice!nano Kyria setup @yannickjmt ?
I wasn't able to get it working on my wireless nice!nano Kyria and I'm wondering if I did something wrong while building it.
Thanks for the encoder resolution tip btw, I was wondering why my left encoder took 2 clicks per key press.
Yes, be careful to have the proper bindings, like for example
sensor-bindings = <&inc_dec_cp C_VOL_DN C_VOL_UP &inc_dec_cp C_BRI_DN C_BRI_UP>;
sensor-bindings = <&inc_dec_kp PG_UP PG_DN &inc_dec_kp LC(LEFT) LC(RIGHT)>;
I also put
CONFIG_EC11=y
CONFIG_EC11_TRIGGER_GLOBAL_THREAD=y
in kyria_left.conf, kyria_right.conf and app/prj.conf (not sure if all are necessary)
Amazing work @stephen , I've NEARLY got it working on both sides.
OK my bad, wasn't working but I had changed the encoder.status to 'okay' in the kyria.dtsi because I was trying to get them working but that was stopping them from being recognized independently! All working now :D
@yannickjmt forgive my ignorance but could you explain your comment about the sensor bindings? You have two lines there, each one using either inc_dec_cp or inc_dec_kp but won't this give you 4 different assignments all at the same time? Have a look at the doc for the difference between kp and cp, otherwise you can go on the discord, not sure what your second problem is.
I have it working on my Sofle v2.
When I rotate the encoders, they don't pick up every tick. This an issue for anyone else? @truonglong88
Working well on my modified ferris sweep! @linkdevk You might have to change your resolution to a lower value, that's what I did and it fixed it.
I have it working on my Sofle v2.
When I rotate the encoders, they don't pick up every tick. This an issue for anyone else? @truonglong88
Put this into your keymap file, below include codes:
&left_encoder { resolution = <1>; };
&right_encoder { resolution = <1>; };
Did the latest update break it? I know the original developer of this PR is not planning on working on it anymore. RIP dual encoders for now
I get this error when i switch to this PR -- Configuring incomplete, errors occurred! FATAL ERROR: command exited with status 1: 'C:\Program Files\CMake\bin\cmake.EXE' '-DWEST_PYTHON=c:\python39\python.exe' '-BF:\GitHubDesktop\app-2.8.3\zmk\app\build' '-SF:\GitHubDesktop\app-2.8.3\zmk\app' -GNinja -DBOARD=nice_nano -DSHIELD=bone_right
I switch back to main and I could build again
I rebased this PR (it was a clean rebase) and pushed it to https://github.com/caksoylar/zmk/tree/split-encoder. I don't have a board with encoders but at least one user on Discord reported it working with the Github Actions workflow using https://zmk.dev/docs/features/beta-testing/#testing-features. I'd imagine that building locally would be no different -- it could be an issue with Zephyr version differences if you switched from main to this branch.
Just tested this with a Sofle RGB using nice!nano. Working as intended!
Are you on 2.5?
Just tested this with a Sofle RGB using nice!nano. Working as intended!
Are you on 2.5?
Yeah. Just forked it yesterday morning.
Is there something wrong with this PR or is it just the lack of time on the core developers' side? It has been in limbo since March.
don't know why, but i can't use this with Github Actions workflow using https://zmk.dev/docs/features/beta-testing/#testing-features! I'm using sofle rgb!
don't know why, but i can't use this with Github Actions workflow using https://zmk.dev/docs/features/beta-testing/#testing-features! I'm using sofle rgb!
At the moment this branch has conflicts with the base branch, which means it can't be merged automatically. That is the reason you cannot use it with '...#testing-features'. If you have enough expertise you can fork it, resolve the conflicts and then use your branch. It is very sad that this branch was never merged. I guess the original author lost interest after being ignored for an indefinite time, and reviewers were/are busy and haven't gotten around to it in time.