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

[Luke Kenneth Casson Leighton]

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


On Sun, Jul 31, 2016 at 6:04 PM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> 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.

 ack.

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

 sounds really sensible

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

 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?


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

 i... ehn?  i implemented that already??   maaan i must have been busy
to have forgotten about it already... :)

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

l.