You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The same issue exists in the hid repo, where I commented about the same issue in 2018: karalabe/hid#7 (comment)
Since the first byte after the report ID can legitimately be a zero byte (a USB packet that starts with a zero byte), this code is broken on linux/macOS, where one has to manually prepend that zero byte report ID. Without prepending the zero byte report ID for linux/macOS, the lower level library will strip the the first byte if it is zero (see below), corrupting the packet:
Hi
Here, the report ID is prepended, but only for Windows:
usb/hid_enabled.go
Lines 126 to 128 in 87927bb
The same issue exists in the hid repo, where I commented about the same issue in 2018: karalabe/hid#7 (comment)
Since the first byte after the report ID can legitimately be a zero byte (a USB packet that starts with a zero byte), this code is broken on linux/macOS, where one has to manually prepend that zero byte report ID. Without prepending the zero byte report ID for linux/macOS, the lower level library will strip the the first byte if it is zero (see below), corrupting the packet:
usb/hidapi/libusb/hid.c
Lines 1003 to 1007 in 87927bb
This is a hard issue to find, as it can be a rare event that a packet starts with a zero byte (after the report ID).
See e.g. this PR which implements this workaround: https://github.com/digitalbitbox/bitbox02-api-go/pull/73/files
The text was updated successfully, but these errors were encountered: