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

[Albert ARIBAUD]

Hi Luke,

Le Mon, 1 Aug 2016 20:31:17 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> ---
> crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
> 
> 
> On Mon, Aug 1, 2016 at 8:21 PM, Albert ARIBAUD
> <albert.aribaud at free.fr> wrote:
> > Le Mon, 1 Aug 2016 01:15:43 +0100
> > Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:
> >  
> >>  my point is: if you've activated 2x the amount of keys because
> >> you're firing on "rows" (16 activated) instead of "columns (only 8
> >> activated), there's now 2x the chance of having a "ghosting"
> >> problem.  
> >
> > *At a given time*, yes, you may think that one active column
> > crossing 16 rows runs twice more chances of ghosting than if it
> > only crosses 8 rows; but then, *over the course of a whole scan*,  
> 
>  logic flaw (i think) - each activation is independent from all
> others.  so with 50% the keyboard's keys "activated" if you use
> columns instead of rows...

I /think/ I see your point now. What you mean is:

Ghosting causes keys on the active column to be seen as depressed when
they are not, and the more keys per column, the more candidates for
ghosting when a column goes active; so, doubling the number of rows
doubles the number of keys on a column and thus doubles the number
of potentially ghosted keys.

However, transposing the matrix also halves the number of columns:
twice more candidate keys for ghosting per column times half less
columns, the total number of candidates remains the same for the whole
matrix.

Or, considered one column at a time: doubling the number of rows
doubles the number of candidate keys for ghosting, but also halves the
number of columns, thus halving the number of key combinations which
will cause ghosting of any of this column's keys. twice more candidate
keys for ghosting per column times half less combinations leading to
actual ghosting : the column's ghosting risk remains unchanged, which
implies that the whole keyboard's ghosting risk remains unchanged.

Anyway:

>  mmmm it's too much for me to think about.  sorry :)  perhaps best is
> to try it, see what happens, after all

Actually I've gotten the split (scan in timer tick context, report in
main context) and row GPIO read reduction committed first, then tried
ghosting with the current setup.

I've checked that ghosting happens with keys E, O, 9 and 3: any three
of these depressed will show the fourth one as depressed too.

Note: my own laptop's keyboard has ghosting too; I'd just had never
ever been affected by it, as I'm not a gamer and do not use emacs
either. O:-)

So, whatever the orientation, we *will* have ghosting. I believe only
gamer keyboards have actual anti-ghosting which they realize either by
just putting each key on its own GPIO or by having a diode in series
with each switch, methods which won't do with the present project
(although some people might want to go and use a non-ghosting keyboard
on their own custom laptop).

Ghosting reduction, OTOH, can be done by laying out the matrix so that
the most current key combinations won't cause ghosting, and by jamming,
that is, not reporting potentially ghost keys.

For the layout, we have to rely on the keyboard manufacturer; we don't
control that.

For jamming: we can detect potential ghosts: that'w whenever all four
keys are seen down on any set of two columns by two rows. I don't
say it's going to be easy, but I've got a few leads.

Now, Which of the four keys we shall report will depend on our priority
policy.

Also: despite dire warnings :) , I've gone and set up a debugging
environment for the NUCLEO through the ST-Link interface. Took me about
one hour to get it working (OpenOCD is a sensitive creature) but it
now does!

Of course, there's no way I can step-debug the whole thing since as soon
as I break, the USB hosts stops seeing answers from the slave, but I
can inspect (possibly ad hoc) state variables and even step-debug
through parts of the code.

Amicalement,
-- 
Albert.