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

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Wed, Aug 3, 2016 at 7:39 AM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> 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.

 that was the logic going through my head, yes.

> 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.

 that's kinda what i figured

> 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.

 .... something like that :)

> 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.

 yeahyeah.  keyboards are *designed* so that the chances of these
keypresses is greatly reduced


> 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,

 yeahyeah - but that costs.

> 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 :)

 they weren't warnings... i just don't like it or see the necessity
for the complexity, i feel that if i have to use a jtag port i'm doing
something wrong, but that's just me

>, 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!

 yay!