Skip to content
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(split): add support for sensors from peripheral #1841

Merged
merged 3 commits into from Aug 28, 2023

Conversation

petejohanson
Copy link
Contributor

This commit adds a new GATT characteristics on the peripheral side and wires it up to read sensor values. The central side subscribes to this new characteristics and replays sensor values on its side.

This is building off the awesome work in #728 but updated to leverage the sensor refactors recently merged in #1039

@petejohanson petejohanson added enhancement New feature or request sensors bluetooth Bluetooth related items encoders labels Jun 19, 2023
@petejohanson petejohanson self-assigned this Jun 19, 2023
@petejohanson petejohanson requested a review from a team as a code owner June 19, 2023 05:19
@petejohanson petejohanson force-pushed the stephen/split-encoder branch 2 times, most recently from 0612d49 to 0da2c45 Compare June 21, 2023 00:12
@burgessa23
Copy link

working fine on Hillside 52

@caksoylar
Copy link
Contributor

Should we update the docs in this PR or do it in another one after merging?

Places to update:

@petejohanson
Copy link
Contributor Author

Should we update the docs in this PR or do it in another one after merging?

Places to update:

* Intro table footnote: https://github.com/zmkfirmware/zmk/blob/main/docs/docs/intro.md?plain=1#L29, https://github.com/zmkfirmware/zmk/blob/main/docs/docs/intro.md?plain=1#L47

* Encoders feature page: https://github.com/zmkfirmware/zmk/blob/main/docs/docs/features/encoders.md?plain=1#L8

Good catch. Updated here in a new commit.

@p3likan0

This comment was marked as resolved.

@p3likan0
Copy link

Working on sofle v2!

Thanks for this amazing job. I hope it arrives to master :)

@mike1808
Copy link

mike1808 commented Jun 26, 2023

I tested on my keyboard and there is one big issue: whenever I on a layer the keyboard registers both mappings: both for the current layer and for the default layer.

Upd: after flashing the build from the CI it works perfectly fine. Something is wrong in my local tooling.

@petejohanson petejohanson force-pushed the stephen/split-encoder branch 2 times, most recently from 585c7f6 to fb19a3f Compare June 28, 2023 21:46
@PhanKhang
Copy link

Tested on SofleV2.1 with nano v2 wired (I don't have any batteries yet). Everything works. Both encoders are working.

@petejohanson
Copy link
Contributor Author

I tested on my keyboard and there is one big issue: whenever I on a layer the keyboard registers both mappings: both for the current layer and for the default layer.

Upd: after flashing the build from the CI it works perfectly fine. Something is wrong in my local tooling.

Fixed, with some help from Mike on Discord.

@DiogoDoreto
Copy link

Just tested it and can confirm this is working with Waterfowl after cherry-picking my config update from DiogoDoreto@fb7c374

Thanks for your work!

@petejohanson petejohanson removed the request for review from Nicell June 29, 2023 22:30
@narze
Copy link

narze commented Jul 8, 2023

Tested on Splitkb Aurora Lily58 and it works, thank you!

@larryare
Copy link

Works on my custom split keyboard flawlessly.

@mike1808
Copy link

I'm curious to know what is this pr blocked on? Does it need a review?

@petejohanson
Copy link
Contributor Author

I'm curious to know what is this pr blocked on? Does it need a review?

Yes, the main thing remaining is review, which will happen when others on the team have bandwidth to do so.

Copy link
Contributor

@lesshonor lesshonor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can report that this PR at least partially fixes a bug introduced in 295ed83, after which encoder events in this config began triggering too often.

I still get 4 calls to volume up or down per-step if the configuration uses resolution (as this shield unfortunately still does in main), but switching to steps/triggers-per-rotation works as expected.

I currently have no way to test the split part of this.

e: After another look this morning, applying the changes in 72ca2fa alone seems to have solved the problem. I am not sure if extracting that commit from the feature PR will break anything. Will have to see if I can rope anyone with a fully-assembled keyboard into testing the bugfix.

@D0hnut5
Copy link

D0hnut5 commented Aug 9, 2023

e: After another look this morning, applying the changes in 72ca2fa alone seems to have solved the problem. I am not sure if extracting that commit from the feature PR will break anything. Will have to see if I can rope anyone with a fully-assembled keyboard into testing the bugfix.

Per lesshonor's roping I tested this on a fully assembled Pillbug Waka. It fixed the issues I was experiencing: every third encoder detent would not send a code and the encoder would not work on layers.

@nobiliana
Copy link

I can report that this PR at least partially fixes a bug introduced in 295ed83, after which encoder events in this config began triggering too often.

I still get 4 calls to volume up or down per-step if the configuration uses resolution (as this shield unfortunately still does in main), but switching to steps/triggers-per-rotation works as expected.

I currently have no way to test the split part of this.

e: After another look this morning, applying the changes in 72ca2fa alone seems to have solved the problem. I am not sure if extracting that commit from the feature PR will break anything. Will have to see if I can rope anyone with a fully-assembled keyboard into testing the bugfix.

Also as per Lesshonor, this PR was tested on a Pillbug with bb40 shield. Encoder performance was showing 2-5 activations per detent; after reflashing with this PR, I am getting the expected 1 activation per detent (1 in 15 seem to be missed, but that could be hardware) using Steps and Trigger.

Split functionality was not tested.

j-w-e added a commit to j-w-e/zmk that referenced this pull request Aug 17, 2023
Copy link
Collaborator

@joelspadin joelspadin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good to me, except I think we should have better error checking when reading data into the sensor_event structs.

int zmk_split_bt_position_released(uint8_t position);
int zmk_split_bt_sensor_triggered(uint8_t sensor_number,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: sensor_event uses sensor_index, while this uses sensor_number. Are these the same thing? If so, making the name consistent would be good.

This also appears to be all the same data as a sensor_event. Could you just pass a pointer to that struct instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So.... struct sensor_event was intended as a data exchange format, which is why it is packed. I'm hesitant to have a data exchange struct also be used for public API like this. Thoughts?

LOG_DBG("[SENSOR NOTIFICATION] data %p length %u", data, length);

struct sensor_event sensor_event;
memcpy(&sensor_event, data, MIN(length, sizeof(sensor_event)));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be a good idea to verify that length >= offsetof(struct sensor_event, channel_data). Otherwise, it would be possible to not write anything to channel_data_size, and then the array size will be a garbage value which may cause other code to read past the end of the array.

Also, we are truncating the array data if given more channels than we support, but we aren't clamping channel_data_size accordingly. This means we're protecting against writing past the end of the array, but not reading past it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a check there.

app/src/split/bluetooth/central.c Outdated Show resolved Hide resolved
app/src/split/bluetooth/central.c Outdated Show resolved Hide resolved
app/src/split/bluetooth/central.c Outdated Show resolved Hide resolved
stephen and others added 3 commits August 27, 2023 14:04
This commit adds a new GATT characteristics on the peripheral side
and wires it up to read sensor values. The central side subscribes
to this new characteristics and replays sensor values on its side.

Co-authored-by: Peter Johanson <peter@peterjohanson.com>
* Don't accept data for the same behavior on multiple layers more than
  once, to avoid duplicate/extraneous triggers.
@petejohanson petejohanson merged commit a92a496 into zmkfirmware:main Aug 28, 2023
83 checks passed
peterpf added a commit to peterpf/zmk-config that referenced this pull request Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bluetooth Bluetooth related items encoders enhancement New feature or request sensors
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet