Thomas Dettbarn has found, analyzed und reported two bugs in imt(4) (see
    https://marc.info/?l=openbsd-tech&m=174841257723328&w=2
and the related messages).

This patch is a fix for the first one.

When processing input reports, hidmt_input identifies groups of contact-
level items by checking for the repetition of an item type - the first
type it has encountered in the report.  This fails for reports starting
with top-level items, which only occur once.  (From the top-level
collection, hidmt includes the contact count and the button states in
its list of input items.)

The 'firstu' value must not be set to a top-level type.  The fix is
trivial, and I don't see any risk of regressions.

OK?

(The second bug is in the *_find_winptp_reports functions in imt(4)
and umt(4), which match wrong report IDs under certain conditions.
Another patch will follow soon; it might be the short workaround from
Thomas - see the imt.c part of his patch - or, perhaps, a more
systematic solution.  I haven't made up my mind yet.)


Index: hidmt.c
===================================================================
RCS file: /cvs/src/sys/dev/hid/hidmt.c,v
diff -u -p -r1.13 hidmt.c
--- hidmt.c	16 Oct 2022 20:17:08 -0000	1.13
+++ hidmt.c	26 Jun 2025 12:40:56 -0000
@@ -42,6 +42,9 @@
 #define DPRINTF(x)
 #endif

+#define IS_TOP_LEVEL_USAGE(u) ((((u) >> 16) & 0xffff) == HUP_BUTTON || \
+    (u) == HID_USAGE2(HUP_DIGITIZERS, HUD_CONTACTCOUNT))
+
 #define HID_UNIT_CM	0x11
 #define HID_UNIT_INCH	0x13

@@ -373,7 +376,7 @@ hidmt_input(struct hidmt *mt, uint8_t *d

 			bzero(&hc, sizeof(struct hidmt_contact));
 		}
-		else if (!firstu)
+		else if (!firstu && !IS_TOP_LEVEL_USAGE(hi->usage))
 			firstu = hi->usage;

 		switch (hi->usage) {