-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
subsys: bluetooth: User data in HID service callback #19692
Conversation
why @nrfconnect/ncs-dragoon is needed to review this? @grochu , likely we need to update the co file |
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 6f92fad33559039433408ad6cd0215f84ef56414 more detailssdk-nrf:
Github labels
List of changed files detected by CI (2)
Outputs:ToolchainVersion: b77d8c1312 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
Allow user to set argument with which notification completion callback is called. Signed-off-by: Pawel Dunaj <[email protected]>
480c338
to
6f92fad
Compare
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publish GitHub Action. |
* @return 0 If the operation was successful. Otherwise, a (negative) error | ||
* code is returned. | ||
*/ | ||
int bt_hids_inp_rep_send_userdata(struct bt_hids *hids_obj, struct bt_conn *conn, |
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.
Looks good, but I would consider deprecating/removing the old approach to keep API simpler.
We may use a Kconfig to toggle between APIs (the Kconfig could be deprecated and old API would be removed at some point). We could also consider simply breaking the API for NCS 3.0 if it's acceptable.
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 should also add a release note (API change)
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 would leave the old api as is to avoid generating noise. Note that if you deprecate the old function people will need to update their app and so waste time for no good reason.
I don't mind mentioning new function in release note but do we really intend to add a release note for any new api function if any random lib/service/module? Any opinion @b-gent ?
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 would not insist here. On the other hand, keeping API smaller/simpler e.g. makes it easier for new users to get started.
|
Allow user to set argument with which notification completion callback is called.