[Arm-netbook] EOMA-68 laptop Keyboard support improvement pushed

[Albert ARIBAUD]

Le Sun, 31 Jul 2016 18:09:11 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> > Better still: transposing the matrix, that is, using 8 columns (ex
> > rows) as outputs and 16 rows (ex columns) as inputs over three banks
> > (GPIOA, B and C), a full scan would need 8*(2 writes + 3 reads) = 40
> > GPIO accesses.  
> 
>  mmmm.... you have to think about the implications of that, first, as
> to whether key-combinations would end up being mis-detected.  if
> double the number of keys are "activated" because you pull "rows" high
> instead of "columns".... you see what i mean?  or does it not matter?

It doesn't. The matrix is really a 16x8 mechanical switch matrix;
switches just connect one "row" and one "column", but "rows" and
"columns" don't have different physical properties; in fact, even
the names "row" and "column" are misnomers. You could switch those names
and the device would work the same.

So really, it's just "a group of 8 lines, and a group of 16 lines, and
up to 128 switches, each switch connecting one member of one group to
one member of the other group", and it's how we use either group that
makes one "a set of outputs" and the other "a set of inputs". The only
constraint is to use all members in each group the same way: either all
columns are outputs and all rows are inputs, or all columns are inputs
and all rows are outputs.

(there is actually a second constraint: "use pull-up inputs, and above
all, use open-drain outputs or else pray that the GPIO pins on the
STM32 are fool-resistant", but that's slightly beside the point.)

> >>  one thing that would be really good would be support for several
> >> key-presses.  the USB-HID "stack" of 6 zeros you are supposed to
> >> fill up and send whenever *any* keypress goes up *or* down.  at
> >> the moment i am only sending *one* keypress (and 5 zeros).  
> >
> > Actually, this is already handled in the current FW (and that was in
> > before I started working on it): try 'sudo usbhid-dump -d 0483:5710
> > -e a' (with*out* the KBD_DEBUG macro) and successively depress Q W
> > E R T Y. You'll see the report filling in.  
> 
>  i... ehn?  i implemented that already??   maaan i must have been busy
> to have forgotten about it already... :)

Git says that was committed on 2015-12-26 round 10PM... Your loss of
memory might have less to do with being busy and more to do with
consequences of end-of-year celebrations. :)

> > What is not handled now is rollover error reporting: when a 7th key
> > is depressed, the report should contain 0x01 in all six places;
> > right now, the 7th key generates no report.  
> 
>  yeahyeah i know about that one.  not sure what to do though.

Either we uphold the 6-key limitation (and then we should follow the
convention about sending rollover error codes as long as more than six
keys are down, ignoring any new depressed key) or we weight keys by
priority and send the 6 most prioritary keys among those depressed
(possibly dropping a less prioritary already-depressed key when a more
prioritary one is depressed).

If we go that way, then we need to define key priorities...

Candidates for priority reporting could be the W, A, S, and D keys. I
would have added I, J, K and L but we have a hard 6-key limit... Player
One will have a slight advantage over Player Two. :)

Amicalement,
-- 
Albert.