Re: New key binding syntax

[Alexandre Garreau]

Le vendredi 5 novembre 2021, 11:03:19 CET Yuri Khan a écrit :
> On Fri, 5 Nov 2021 at 16:13, Alexandre Garreau <galex-713@galex-713.eu> 
wrote:
> > so it’s like a down, b down, …, f down… and then until I release any
> > key between a and f, if I press down “g”, the keyboard won’t say
> > anything to the application/OS?
> 
> As I said, it depends.

No I really didn’t understand.  You said the rollover key number changed, 
not that once it was overtook, the behavior varied.  And you said that 
number was most of time 6.  What I want to understand is what goes wrong 
then… presses unreported? releases falsely reported in some order?

> (Also, I’d like to see you do that with just
> your left hand.)

While only the left hand? with both it’s possible.

>     q w E r t
>      A s D F G
>       z x C v B

Well I have not polydactilia, so I cannot easily because I have only five 
fingers with the left hand (but I can place a finger between D F and C to 
press them with one finger, and on B and G with the remaining finger, but 
I’d need to press strong and would risk accidental releases).  But I 
neither user qwerty, and in both azerty (although then it’s difficult and I 
use the right hand only for the B) and bepo I can easily do that with both 
hands.

Anyway, I used sequential letters of the alphabet not to have to list them 
all and try to reduce confusion and example minimality, but I failed, 
keyboards cannot be simple I guess :'D

Of course, then, ideally, the user and/or app dev should take into 
consideration ergonomy and biomechanical limits into choices.

> > wdym by “simultaneously”? “close enough in time of pressing”? or
> > “while
> > the others haven’t been released yet”?
> 
> The latter.
> 
> > what? I thought the usb kbd firmware worked by sending events that
> > triggered interruptions, not that it stored keystate itself :o I
> > thought keystate was saved and registered application-side, with each
> > event
> Well, this explains your reactions. What travels over the wire is the
> state (level), not the changes (edges). It is the OS, input subsystem
> of the desktop, and possibly toolkit, that translates that into press,
> release, and autorepeat events.

For the autorepeat I could imagine, but for release I had no idea… but 
doesn’t the keyboard generates hardware events? to interrupt OS when 
there’s a change? it’s not scanned at each tick, right?

> Otherwise, for example, what would happen if you held down a bunch of
> keys and then unplugged the keyboard? Should the host system remember
> that these keydowns originally came from device X and auto-generate
> posthumous keyups for them when device X is unplugged?

I guess it should consider all keys unpressed again, since most of time 
there’s an elasticity/spring/etc. under it.

But right, I see, and 105 bits is too much I guess, I see.  I thought the 
kbd didn’t worked as a parallel port, but as a serial port, and 105 bit 
per, dunno, ms, didn’t looked like a lot.

> (It is also the OS and the desktop’s input subsystem that interprets
> keyboard layouts and turns a Shift+AB01 into a capital Z on a US
> system or capital Y on a German system. But you probably knew that.)

You guessed well) I even worked a lot on tweaking varous layouts