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

[Albert ARIBAUD]

Hi Luke,

Le Sun, 31 Jul 2016 16:48:58 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> a écrit:

> ---
> crowd-funded eco-conscious hardware:
> https://www.crowdsupply.com/eoma68
> 
> 
> On Sun, Jul 31, 2016 at 3:03 PM, Albert ARIBAUD
> <albert.aribaud at free.fr> wrote:
> > Hi all,
> >
> > I have gone ahead and pushed my latest round of improvements for
> > keyboard support in the EOMA-68 laptop EC firmware.
> >
> > The new feature is support for modifiers (ctrl, shift, alt, GUI).  
> 
>  hooray!   awesome, albert.  oh, one other thing, you probably
> noticed, i do polling not any kind of interrupt-driven stuff.  i'd
> like to keep it that way for now as it would massively complicate
> adding other hardware support (I2C, etc.)

Agreed re interrupts; I don't intend to introduce any interrupt.

There is one structural change I'd like to make, though, and it is to
split the handling into a GPIO scanning part which would be *very*
tight and *very* short code running directly from the timer tick (that
would allow getting rid of the udelay() call BTW) and a USB reporting
part which would run in the main loop. Roughly, the scanning part would
raise a flag to tell the reporting part as soon as it sees a raw scan
difference, and the reporting part would lower that flag wenever it
sends the report for the last scan available.

But before I get there, I want to finish optimizing GPIO use. I've
already lowered column GPIO writes from 18 down to 2 per column, so
right now, scanning the whole matrix requires 16*(2 writes + 8 reads)=
160 GPIO accesses (down from an original 416).

But all rows could be read in two global GPIO bank reads, then matched
against the individual GPIO masks in the row table; that would shave 6
GPIO reads per column, lowering the total to 16*(2 writes + 2 reads) =
64 GPIO accesses.

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.

From there, there is still a way to lower that to 32 GPIO accesses
by setting and clearing output GPIOs in a single write using BSRR, but
it would require extending LIBOPENCM3 with an added "gpio_set_clear()
function. Hey, why not, after all. :)

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

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.

Amicalement,
-- 
Albert.