From 5a079a2d114f96d4847d1ee305d5b7c16eeec50e Mon Sep 17 00:00:00 2001
From: 3gg <3gg@shellblade.net>
Date: Sat, 27 Dec 2025 12:03:39 -0800
Subject: Initial commit

---
 contrib/SDL-3.2.8/src/hidapi/netbsd/README.md | 29 +++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 contrib/SDL-3.2.8/src/hidapi/netbsd/README.md

(limited to 'contrib/SDL-3.2.8/src/hidapi/netbsd/README.md')

diff --git a/contrib/SDL-3.2.8/src/hidapi/netbsd/README.md b/contrib/SDL-3.2.8/src/hidapi/netbsd/README.md
new file mode 100644
index 0000000..f1b12a0
--- /dev/null
+++ b/contrib/SDL-3.2.8/src/hidapi/netbsd/README.md
@@ -0,0 +1,29 @@
+Implementation Notes
+--------------------
+NetBSD maps every `uhidev` device to one or more `uhid`
+devices. Each `uhid` device only supports one report ID.
+The parent device `uhidev` creates one `uhid` device per
+report ID found in the hardware's report descriptor.
+
+In the event there are no report ID(s) found within the
+report descriptor, only one `uhid` device with a report ID
+of `0` is created.
+
+In order to remain compatible with existing `hidapi` APIs,
+all the `uhid` devices created by the parent `uhidev` device
+must be opened under the same `hid_device` instance to ensure
+that we can route reports to their appropriate `uhid` device.
+
+Internally the `uhid` driver will insert the report ID as
+needed so we must also omit the report ID in any situation
+where the `hidapi` API expects it to be included in the
+report data stream.
+
+Given the design of `uhid`, it must be augmented with extra
+platform specific APIs to ensure that the exact relationship
+between `uhidev` devices and `uhid` devices can be determined.
+
+The NetBSD implementation does this via the `drvctl` kernel
+driver. At present there is no known way to do this on OpenBSD
+for a `uhid` implementation to be at the same level as the
+NetBSD one.
-- 
cgit v1.2.3