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

[Albert ARIBAUD]

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).
Previously, these were sent as key codes, now they are sent within the
modifier. For those to whom this is pure gibberish, it basically means
that now "shift-a" *will* show as "A" (unless you've hit the Caps Lock
key, of course, in which case "shift-A" will show as "a"), Alt-tab
*will* cycle through your apps "Ctrl-C" *will* break that running
process in your console, etc.

Basically, the keyboard is now as functional as any other USB keyboard
(except for two keys on the AZERTY matrix which seem to differ wrt the
QWERTY matrix; that's a trivial issue and precisely the kind of thing
I've initially set out to find and fix).

I've also made some less visible changes, mainly to optimize GPIO
access (for which there is still some improvement simmering gently
here).

Amicalement,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
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.)

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

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la

[Albert ARIBAUD]

Hi Luke,

Le Sun, 31 Jul 2016 16:48:58 +0100

Post by Luke Kenneth Casson Leighton
---
https://www.crowdsupply.com/eoma68
On Sun, Jul 31, 2016 at 3:03 PM, Albert ARIBAUD

Post by Albert ARIBAUD
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. :)

Post by Luke Kenneth Casson Leighton
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,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
Hi Luke,
Le Sun, 31 Jul 2016 16:48:58 +0100

Post by Luke Kenneth Casson Leighton
---
https://www.crowdsupply.com/eoma68
On Sun, Jul 31, 2016 at 3:03 PM, Albert ARIBAUD

Post by Albert ARIBAUD
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.

Post by Albert ARIBAUD
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

Post by Albert ARIBAUD
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?

Post by Albert ARIBAUD
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. :)

:)

Post by Albert ARIBAUD

Post by Luke Kenneth Casson Leighton
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... :)

Post by Albert ARIBAUD
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.p

[Albert ARIBAUD]

Le Sun, 31 Jul 2016 18:09:11 +0100

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD
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.)

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD

Post by Luke Kenneth Casson Leighton
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. :)

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD
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 ARIBAUD]

Le Sun, 31 Jul 2016 19:44:47 +0200

Post by Albert ARIBAUD
Le Sun, 31 Jul 2016 18:09:11 +0100

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD
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.)

Thinking more about it, maybe you were thinking about up to 16 keys
being depressed rather than 8, and the inputs' fan-ins adding up to
twice more and the output's fan-out not being able to cope, leading to
the input voltage not falling low enough for the keys to be detected
as down.

Looking at the data sheet, and taking the worst case:

- V(IL) is either 1.06V or 1.46V depending on the pin. Worst case:
1.06V.

- V(OL) is 0.4V across all output configurations for | I(IO) | < 8 mA
and V(DDIO) > 2.7V.

We have V(DDIO) = VDD = 3.3V, so V(DDIO) > 2.7V is covered; we need to
check if we have | I(IO) | < 8 mA.

I(IO) will be proportional to the number of switches closed on a given
column when that column is drained to VSS. Worst case is all 8 (for
the current firmware) switches closed. From the datasheet:

- Pull-up resistances are between 25 and 55 kOhm. Worst case, 25 kOhm.

- 8 parallel pull-ups would yield 25/8 = 3.12 kOhm.

- 3.3V / 3.12 kOhm ~ 1.06 mA, way below 8 mA.

With 16 inputs, we halve the overall impedance down to 1.6 kOhm and
double the current to 2.12 mA, still way below the 8 mA.

(also, we are far below the total power consumption of 120 mA. Just
being exhaustive here.)

I haven't found any other constraint.

Technically, I should have taken the switches' impedance (about 200
Ohm) into account in case it worsens things; but those 200 Ohms
would increase the pull-up impedance and reduce the current, so
actually a 0 Ohm switch impedance is the worst case already.

So I think that's OK, but you know what? Let me try it. :)

Amicalement,

[Luke Kenneth Casson Leighton]

Post by Albert ARIBAUD
Thinking more about it, maybe you were thinking about up to 16 keys
being depressed rather than 8, and the inputs' fan-ins adding up to
twice more and the output's fan-out not being able to cope, leading to
the input voltage not falling low enough for the keys to be detected
as down.

not quite... maybe i was but hadn't quite got it through from
subconscious into words.. but that's a good point - i was thinking if
you used 8 fan-in and press 9 keys... if you have 16 fan-in and press
9 keys...

basically the 16 fan-in it "activates" 50% less of the matrix.

Post by Albert ARIBAUD
Technically, I should have taken the switches' impedance (about 200
Ohm) into account in case it worsens things; but those 200 Ohms
would increase the pull-up impedance and reduce the current, so
actually a 0 Ohm switch impedance is the worst case already.
So I think that's OK, but you know what? Let me try it. :)

:)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phco

[Albert ARIBAUD]

Bonjour,

Le Sun, 31 Jul 2016 20:51:51 +0100

On Sun, Jul 31, 2016 at 8:34 PM, Albert ARIBAUD

Post by Albert ARIBAUD
Thinking more about it, maybe you were thinking about up to 16 keys
being depressed rather than 8, and the inputs' fan-ins adding up to
twice more and the output's fan-out not being able to cope, leading
to the input voltage not falling low enough for the keys to be
detected as down.

not quite... maybe i was but hadn't quite got it through from
subconscious into words.. but that's a good point - i was thinking if
you used 8 fan-in and press 9 keys... if you have 16 fan-in and press
9 keys...
basically the 16 fan-in it "activates" 50% less of the matrix.

Hmm... Not getting what you're hinting at. Can you develop?

Post by Albert ARIBAUD
Technically, I should have taken the switches' impedance (about 200
Ohm) into account in case it worsens things; but those 200 Ohms
would increase the pull-up impedance and reduce the current, so
actually a 0 Ohm switch impedance is the worst case already.
So I think that's OK, but you know what? Let me try it. :)

:)

I'll do that tomorrow evening, though. Real World is looming. :)

Amicalement,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
Bonjour,
Le Sun, 31 Jul 2016 20:51:51 +0100

On Sun, Jul 31, 2016 at 8:34 PM, Albert ARIBAUD

Post by Albert ARIBAUD
Thinking more about it, maybe you were thinking about up to 16 keys
being depressed rather than 8, and the inputs' fan-ins adding up to
twice more and the output's fan-out not being able to cope, leading
to the input voltage not falling low enough for the keys to be
detected as down.

not quite... maybe i was but hadn't quite got it through from
subconscious into words.. but that's a good point - i was thinking if
you used 8 fan-in and press 9 keys... if you have 16 fan-in and press
9 keys...
basically the 16 fan-in it "activates" 50% less of the matrix.

Hmm... Not getting what you're hinting at. Can you develop?

it's related to mis-detection of keys. if you press certain
combinations in certain ways, you get "ghost" keys that you can't tell
if they were actually pressed or not. by reducing the number of keys
that are "live" (16 fan-in only activates up to 8 maximum where as 8
fan-in could activate up to 16 maximum) you reduce the possibility of
"ghosting".

there was an article online about it... ah! found it:
http://pcbheaven.com/wikipages/How_Key_Matrices_Works/

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[Albert ARIBAUD]

Le Sun, 31 Jul 2016 21:56:13 +0100

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD
Hmm... Not getting what you're hinting at. Can you develop?

it's related to mis-detection of keys. if you press certain
combinations in certain ways, you get "ghost" keys that you can't tell
if they were actually pressed or not. by reducing the number of keys
that are "live" (16 fan-in only activates up to 8 maximum where as 8
fan-in could activate up to 16 maximum) you reduce the possibility of
"ghosting".
http://pcbheaven.com/wikipages/How_Key_Matrices_Works/

Ok, got your point now.

Too late today to do probabilities (heck, even in the morning right
after my coffee shot I would not trust my skills in probabilities).
Still, I intuitively (yeah, I know) think there is no reduction in the
risk of ghosting when transposing the matrix, because there is no
asymmetry in the ghosting problem; ghosting occurs as soon as three of
the four connections between two rows and two columns are closed: at
that point, there is no way to tell whether the fourth connection is
open or closed, and this, regardless of any notion of "row", "column",
or "activity".

IOW, whether or not a given state of the keyboard matrix will exhibit
ghosting is only defined by the distribution of the depressed keys on
the matrix, not by the rotation with which we look at that matrix or
whether it currently has an active column.

Amicalement,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
Le Sun, 31 Jul 2016 21:56:13 +0100

Post by Luke Kenneth Casson Leighton

Post by Albert ARIBAUD
Hmm... Not getting what you're hinting at. Can you develop?

it's related to mis-detection of keys. if you press certain
combinations in certain ways, you get "ghost" keys that you can't tell
if they were actually pressed or not. by reducing the number of keys
that are "live" (16 fan-in only activates up to 8 maximum where as 8
fan-in could activate up to 16 maximum) you reduce the possibility of
"ghosting".
http://pcbheaven.com/wikipages/How_Key_Matrices_Works/

Ok, got your point now.
Too late today to do probabilities (heck, even in the morning right
after my coffee shot I would not trust my skills in probabilities).
Still, I intuitively (yeah, I know) think there is no reduction in the
risk of ghosting when transposing the matrix, because there is no
asymmetry in the ghosting problem; ghosting occurs as soon as three of
the four connections between two rows and two columns are closed: at
that point, there is no way to tell whether the fourth connection is
open or closed, and this, regardless of any notion of "row", "column",
or "activity".
IOW, whether or not a given state of the keyboard matrix will exhibit
ghosting is only defined by the distribution of the depressed keys on
the matrix, not by the rotation with which we look at that matrix or
whether it currently has an active column.

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.

i think.

too much for my brain to cope with....

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Se

[Albert ARIBAUD]

Le Mon, 1 Aug 2016 01:15:43 +0100

Post by Luke Kenneth Casson Leighton
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*, 16 columns run twice more
chances of ghosting than 8 columns do; it cancels out.

Or you can consider this exercize:

Consider our QWERTY laptop keyboard's columns 8 and 9 and rows 2 and 3.
Here they are represented with the keys at their intersections :


8 9
| |
| |
KEY_E | | KEY_O
----------------X-----------X------------ 2
| |
| |
| |
KEY_3 | D | KEY_9
---------------- -----------X------------ 3
| |
| |
| |

The "X" marks at intersections denote a depressed key, which connects
its row and column; so in the example above, the three keys E, O and 9
are depressed.

First exercize: let's "activate" column 8 and read rows 2 and 3,
"Activating" column 8 means pulling it down hard, which drags row 2
down, which drags column 9 down, which drags row 3 down, so we read
both rows 2 and 3 down and conclude that keys E and 3 are down: key
3 is ghosted.

Second exercize: same keyboard with same depressed keys, but instead of
activating column 8 and reading rows, we activate row 3 and read
columns. Pulling row 3 down hard drags column 9 down, which drags row 2
down, which drags column 8 down, so we read both columns 8 and 9 down
and conclude that keys 3 and 9 are down: key 3 is ghosted.

You can try this exhaustively if you like: for every keyboard state
defined by which of its keys are down, you will end up with exactly the
same set of ghosted keys whether you activate columns and read rows
or activate rows and read columns.

Post by Luke Kenneth Casson Leighton
i think.
too much for my brain to cope with....

:)

Amicalement,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
Le Mon, 1 Aug 2016 01:15:43 +0100

Post by Luke Kenneth Casson Leighton
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...

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

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom

[Albert ARIBAUD]

Hi Luke,

Le Mon, 1 Aug 2016 20:31:17 +0100

Post by Luke Kenneth Casson Leighton
---
https://www.crowdsupply.com/eoma68
On Mon, Aug 1, 2016 at 8:21 PM, Albert ARIBAUD

Post by Albert ARIBAUD
Le Mon, 1 Aug 2016 01:15:43 +0100

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
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,

[Luke Kenneth Casson Leighton]

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

Post by Albert ARIBAUD
Hi Luke,
Le Mon, 1 Aug 2016 20:31:17 +0100

Post by Luke Kenneth Casson Leighton
---
https://www.crowdsupply.com/eoma68
On Mon, Aug 1, 2016 at 8:21 PM, Albert ARIBAUD

Post by Albert ARIBAUD
Le Mon, 1 Aug 2016 01:15:43 +0100

Post by Luke Kenneth Casson Leighton
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...

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.

Post by Albert ARIBAUD
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

Post by Albert ARIBAUD
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 :)

Post by Albert ARIBAUD

Post by Luke Kenneth Casson Leighton
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

Post by Albert ARIBAUD
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.

Post by Albert ARIBAUD
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

Post by Albert ARIBAUD
, 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!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send larg