Re: kern/60918: Keyboard modifier keys are not checked correctly when sent simultaneously

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60918; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/60918: Keyboard modifier keys are not checked correctly when sent simultaneously
Date: Sun, 25 Oct 2026 08:28:49 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("Michael van Elst via gnats") writes:
 
 > We have a second decoder for USB HID reports that handles key status
 > for "Dynamic Variable" (used by modifiers) values separate from
 > "Selectors" (used by regular keys) and transmits the DV events first.
 > 
 > I'm not sure if that is the correct behaviour, but it solves the
 > problem.
 > 
 > Another possibility is to generate events for the modifier keycodes
 > 224..231 first, or by simply scanning the keycodes in reverse order.
 
 FreeBSD orders events by 'regular keys up', 'modifier keys up',
 'modifier keys down' 'regular keys down'. This is done by scanning
 the key status information 4 times. "modifiers" are identified
 by their keycode range (224..231). That is similar to the second
 method above.
 
 
 Linux has another method. It sorts processing of usages by the order
 they appear in the report descriptor (with some exceptions for other
 input devices, in particular Wacom tablets). This is a more refined
 version of the first method above.
 
 
 The standard is unclear. While it specifies that order of keypresses
 in a single report is undefined and needs to be resolved by "host software",
 it explicitely mentions only the order of keycodes in an array item.
 
 It also defines that modifiers "should" use a bitmask (dynamic flags)
 while non-modifiers "must" use an array of keycodes. It also suggests
 that keycodes should be interpreted according to the modifiers,
 
 It never gives an example of changing modifiers and keys in an array
 at the same time. The standard also suggests that other keys (like
 function keys) can be used like modifiers and are sent together in
 a keycode array.
 
 
 So, keyboards shouldn't send multiple events in a single report
 because of these ambiguities, and "host software" already uses
 different ways to resolve such reports in a meaningful manner.