Re: New key binding syntax

[Yuri Khan <yuri.v.khan@gmail.com>]

On Fri, 5 Nov 2021 at 13:08, Alexandre Garreau <galex-713@galex-713.eu> wrote:

> > The rollover behavior works entirely on the application side, where
> > the OS and the GUI toolkit send events like “the key at position AB02
> > was pressed while the left Alt is down; by the way, the character for
> > this key in the current layout is x”. If the application reacts to key
> > press and autorepeat events and takes the character and modifiers from
> > them immediately, the “AC01 down (char a), AB05 down (char b), AC01 up
> > (char a), AB05 up (char b)” sequence results in an “a then b” text
> > input. But some applications (notably games) just track the whole bit
> > array of keys.
>
> But what happens after 7 consecutive down on a typical keyboard then?

Technically what happens in that highly theoretical example depends on
the firmware implementation; in the USB protocol, there is provision
for the keyboard reporting “the user held down so many keys I can’t
accurately report them all”.

> why this limitation since each key succeeds the previous one?

Each key does not “succeed” the previous one. Keyboards are not only
used for text input but also for gaming and (rarely, with advanced
users) chord input, and they must be able to report at least a few
keys held down simultaneously, and the exact moment they are released.
In a game, it’s not an unusual situation that you hold down one key to
crouch, another to keep moving (crawling?) forward, and a third one to
turn left or right, while periodically pressing a fourth key to fire.
If the keyboard reports the release too early, you stand back up, and
your enemies notice you.

The limitation is about the keyboard state report having a manageable
size. With this particular format, the 8 modifiers are reported as a
bit mask in a single byte, then there is a mostly reserved byte, then
6 bytes contain the codes of keys currently held down.