gh-libusb/hidapi

Watch

Fork 0

libusb: add configurable write and report timeouts #832

Merged

mbcinergy merged 2 commits from master into master

2026-07-29 05:48:35 -05:00

mbcinergy commented

2026-07-28 06:41:16 -05:00

(Migrated from github.com)

Add libusb-specific timeout setters for hid_write(), hid_send_output_report(), and hid_send_feature_report().

Each operation keeps its existing 1000 ms default. A timeout of 0 waits indefinitely, matching libusb semantics. Control-endpoint fallback writes use the configured hid_write() timeout, while direct output-report and feature-report operations use their respective settings.

Add libusb-specific timeout setters for `hid_write()`, `hid_send_output_report()`, and `hid_send_feature_report()`. Each operation keeps its existing 1000 ms default. A timeout of 0 waits indefinitely, matching libusb semantics. Control-endpoint fallback writes use the configured `hid_write()` timeout, while direct output-report and feature-report operations use their respective settings.

Youw commented

2026-07-28 12:36:43 -05:00

(Migrated from github.com)

Thanks for the contribution!
This kind of mirrors the hid_winapi_set_write_timeout, except hid_winapi_set_write_timeout only changes the timeout for hid_write while hid_libusb_set_write_timeout changes timtout for all of hid_write, hid_send_feature_report and hid_send_output_report.

I get that most likely it doesn't make much sense to configure those separately (does it?), but I don't like the idea of having a similar configuration function (with similar name) but with slightly different behavior. And updating Windows implementation to update all 3 timeouts is not as trivial as one might expect.

@mbcinergy what are you thoughs on this?

Thanks for the contribution! This kind of mirrors the `hid_winapi_set_write_timeout`, except `hid_winapi_set_write_timeout` only changes the timeout for `hid_write` while `hid_libusb_set_write_timeout` changes timtout for all of `hid_write`, `hid_send_feature_report` and `hid_send_output_report`. I get that most likely it doesn't make much sense to configure those separately (does it?), but I don't like the idea of having a similar configuration function (with similar name) but with slightly different behavior. And updating Windows implementation to update all 3 timeouts is not as trivial as one might expect. @mbcinergy what are you thoughs on this?

mbcinergy commented

2026-07-29 03:21:35 -05:00

(Migrated from github.com)

I thought it made sense to use it for all writing functions, as the name suggests. The function i need it in is actually hid_send_output_report, which for libusb backend is also used by hid_write. So they are more or less connected together functionality wise.

I don't think it makes sense to use different timeouts for hid_send_feature_report either. We could leave it at fixed 1000ms, but IMO that would be strange behaviour as well.

With winapi backend there is another thing, because the hid_send_output_report functions uses HidD_SetOutputReport which has a fixed 5000ms timeout. This is already different than the default 1000ms for libusb backend. Not sure how you could change that.

We could add a separate timeout parameter for the reading functions, but that might be something for another PR. I have left the reading functions with the default 1000ms for now (and we already have hid_read_timeout).

I thought it made sense to use it for all writing functions, as the name suggests. The function i need it in is actually `hid_send_output_report`, which for libusb backend is also used by `hid_write`. So they are more or less connected together functionality wise. I don't think it makes sense to use different timeouts for `hid_send_feature_report` either. We could leave it at fixed 1000ms, but IMO that would be strange behaviour as well. With winapi backend there is another thing, because the `hid_send_output_report` functions uses `HidD_SetOutputReport` which has a fixed 5000ms timeout. This is already different than the default 1000ms for libusb backend. Not sure how you could change that. We could add a separate timeout parameter for the reading functions, but that might be something for another PR. I have left the reading functions with the default 1000ms for now (and we already have `hid_read_timeout`).

Youw commented

2026-07-29 03:42:26 -05:00

(Migrated from github.com)

functions uses HidD_SetOutputReport which has a fixed 5000ms timeout. ... Not sure how you could change that.

That can be changed by using DeviceIOControl directly, instead of using HidD_SetOutputReport wrapper, but that would be a separate change

hid_send_output_report, which for libusb backend is also used by hid_write.

I don't believe that's the case. It is for macOS backend, but for libusb backend all 3 functions have their own implementation with a separate libusb_control_transfer invocation

Lets introduce 3 separate:

hid_libusb_set_write_timeout
hid_libusb_set_send_output_report_timeout
hid_libusb_set_send_feature_report_timeout

This way it will be a 100% clear what is going on and what it controls.
And we can match the implementation for other backends in the future.

> functions uses HidD_SetOutputReport which has a fixed 5000ms timeout. ... Not sure how you could change that. That can be changed by using DeviceIOControl directly, instead of using HidD_SetOutputReport wrapper, but that would be a separate change > hid_send_output_report, which for libusb backend is also used by hid_write. I don't believe that's the case. It is for macOS backend, but for libusb backend all 3 functions have their own implementation with a separate `libusb_control_transfer` invocation --- Lets introduce 3 separate: - `hid_libusb_set_write_timeout` - `hid_libusb_set_send_output_report_timeout` - `hid_libusb_set_send_feature_report_timeout` This way it will be a 100% clear what is going on and what it controls. And we can match the implementation for other backends in the future.

mbcinergy commented

2026-07-29 03:50:17 -05:00

(Migrated from github.com)

for libusb backend the hid_write uses the hid_send_output_report function when there is no interrupt out endpoint.

I'm fine with adding separate timeout functions, but in this case hid_write would actually use the output_report_timeout instead when there is no interrupt out endpoint.

for libusb backend the `hid_write` uses the `hid_send_output_report` function when there is no interrupt out endpoint. I'm fine with adding separate timeout functions, but in this case `hid_write` would actually use the output_report_timeout instead when there is no interrupt out endpoint.

Youw commented

2026-07-29 03:52:50 -05:00

(Migrated from github.com)

uses the hid_send_output_report function when there is no interrupt out endpoint

Ah right, that case...
Then lets extract static int hidapi_internal_send_output_report which explicitly accepts the timeout parameter. And use it from both hid_write and hid_send_output_report

> uses the hid_send_output_report function when there is no interrupt out endpoint Ah right, that case... Then lets extract `static int hidapi_internal_send_output_report` which explicitly accepts the timeout parameter. And use it from both `hid_write` and `hid_send_output_report`

👍 1

Youw (Migrated from github.com) approved these changes

2026-07-29 05:43:23 -05:00

Youw (Migrated from github.com) left a comment

This looks fine. I'll run AI review before merging

Youw commented

2026-07-29 08:33:39 -05:00

(Migrated from github.com)

Interesting fact: I presume this entire code was handwritten by a human (@mbcinergy), but I asked codex to update the PR description and make a merge-commit, so it did and added codex annotation to the commit message body.
That is technically correct, but no code was actually touched by codex in this instance.

Interesting fact: I presume this entire code was handwritten by a human (@mbcinergy), but I asked codex to update the PR description and make a merge-commit, so it did and added codex annotation to the commit message body. That is technically correct, but no code was actually touched by codex in this instance.

mbcinergy commented

2026-07-29 09:30:24 -05:00

(Migrated from github.com)